The short answer is; I believe so, but my original submission
was long and more detailed and was wiped out because I forgot to
give it a title (not very friendly, Mr. Forum-Coder!!).
I have set up both servers (development and production) to be
as identical as possible (the development one's a Compaq ProLiant
ML-350 dual-processor beast, running Windows Server 2003 Standard,
the production is a VMWare virtual machine running Windows Server
2003 Standard). Both licensed copies of CF-MX 6.1 are configured
the same.
I took one of many web sites I have running on both machines,
and visually updated it. The old web site was (and still is)
running fine on both machines. I cloned the web site, and re-did
the graphics, buttons, page layouts (converting the site to
DreamWeaver Templates in the process). I made one-for-one copies of
each page, and where there was CF code on a page, I cut-n-pasted
everything from the old (working) page to the new page. Visually
the pages looked different, but the coding and output was exactly
the same.
Once the site was converted and working properly on the
development server, I then added a couple of small enhancements to
some - not a lot - of the pages, to respond to user requests for
more features. The page that is crashing was actually my
Application.cfm page in the protected (login required) area, and
this page was not changed at all except to add a few more field
pulls from the corporate LDAP database to support the new features.
My modus operandi in this environment is to test thoroughly
on the fully-functional development server first, then copy the
entire web site from one server to the other when going live,
change one line in the top-level Application.cfm file to indicate
which server it's on, and then test it out on the operational
server.
This I did, and everything was working fine for about a
month. Then the production server started spitting this error on
this one page in this one web site - all the other CF web sites
hosted on the production server continued - and still continue - to
function correctly.
Hindsight on this is fuzzy, but I believe my problem started
when I chased down a time-reporting error introduced when the
daylight savings time shift happened. Old JREs had a "bug" that
still reported time in old format, even when the server OS had been
patched correctly (
http://java.sun.com/developer/technicalArticles/Intl/USDST/).
I updated both JREs on both servers to j2sdk1.4.2_12. The developer
server continued to work properly with all the sites, and the time
was reported correctly. The production server continued to work
correctly on all sites except this one.
I just noticed that the Sun web page referenced above lists
j2sdk1.4.2_13 as the one with the DST patch, not j2sdk1.4.2_12
(which it did list before when I was troubleshooting). I'm not
hopeful, but I'll try bumping my JRE up another notch to see if
that works.
Thanks for your reply. All ideas welcome; I'm stumped on this
one.
Gene
8
Replies
AdChoices