Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / April 2005

Tip: Looking for answers? Try searching our database.

Static initilizer failed to execute?

Thread view: 
Virgil Green - 29 Apr 2005 18:02 GMT
We had what I consider to be an extremely odd occurrence this morning. A
class that has not been changed for over 2 years appears to have failed to
run its static initializer code.

Because the code in question accesses another system, I track execution
times via logging messages. This class is loaded every morning. I've noted
that I have the messages logged showing that the static initializer code
*has* executed every morning for as far back as I have logs, back to March
18, 2005.

For some very odd reason, the code seems not to have executed this morning.
When I shut down the JVM and restarted it, the code executed as expected.

So, my question is whether anyone has encountered a situation in which a
static initializer simply failed to execute when there was no known
modifications to code or environment?

I'm completely befuddled by this one. Technically, the only evidence I have
is that no log entries were made, but I have no more reason to doubt the
logging mechanism that I do the static initializer code itself.

Here is the static initializer code. I haven't provided a complete, working
example because this is not a reproducible problem - it seems to be a
complete anomaly:

 static
 {
   try
   {
     TimingReporter resolveDuration = new TimingReporter("Resolve to file "
+ FILE_NAME);
     library =
LibraryListManager.getInstance().resolveLibraryName(FILE_NAME,
OBJECT_TYPE).trim();
     resolveDuration.report();
   } catch (Exception e)
   {
     e.printStackTrace();
   }
 }

I would expect one of two things to happen:

1) the library variable would be populated and the resolveDuration.report()
call would produce a log entry telling me how long the operation took to
complete.
2) there was an error (exception) in the resolveLibraryName() method and I
would get a stacktrace printed.

Neither of those happened, so I'm also investigating whether there was some
odd occurence within resolveLibraryName. However, since I only see two paths
through this static initializer and since both of those paths should have
produced some observable output (either a log message or a printed
stacktrace), I question whether the static initializer ran at all.

All thoughts appreciated.

Signature

Virgil

John C. Bollinger - 29 Apr 2005 20:47 GMT
[...]

> Here is the static initializer code. I haven't provided a complete, working
> example because this is not a reproducible problem - it seems to be a
[quoted text clipped - 23 lines]
> 2) there was an error (exception) in the resolveLibraryName() method and I
> would get a stacktrace printed.

3) Something in the try block threw an Error, in which case the above
code would print nothing (but something else would need to handle the
error to prevent the application from crashing).

4) The static initializer was never entered in the first place, for
reasons centered elsewhere.

Signature

John Bollinger
jobollin@indiana.edu

Virgil Green - 29 Apr 2005 20:59 GMT
> [...]
>
[quoted text clipped - 29 lines]
> code would print nothing (but something else would need to handle the
> error to prevent the application from crashing).

In this particular case, crashing is exactly what I would expect, but thanks
for the reminder that an unchecked exception might have been thrown.

> 4) The static initializer was never entered in the first place, for
> reasons centered elsewhere.

Reason's which I couldn't fathom, but could not yet discard.

As it happens, you may have seen my other post where I finally found the
stacktrace I had been expecting to find. I'll need to go in and make this
code a bit more robust.

Thanks for your comments.

Signature

Virgil

Thomas G. Marshall - 30 Apr 2005 14:19 GMT
John C. Bollinger coughed up:

> [...]
>
[quoted text clipped - 32 lines]
> 4) The static initializer was never entered in the first place, for
> reasons centered elsewhere.

5) There is something wrong (but does not throw an exception) with the code
in this section, or in something external that the code relies on that has
changed recently.  There are a lot of things that this code all by itself
depends on:

       TimingReporter resolveDuration =
               new TimingReporter("Resolve to file "
               + FILE_NAME);
       library = LibraryListManager.getInstance().
               resolveLibraryName(FILE_NAME,
               OBJECT_TYPE).trim();
       resolveDuration.report();

In such cases, I would check my assumptions.  I would first take a quick
look at that external system you mentioned, and/or look at a complete
(source code) change log at or near the day this anomoly started happening.

Can you put some sort of date stamp at the begining and end of the static
block (NOT using TimingReporter).  Let it pummel info into a safe place, and
then you can compare it against what the TimingReporter has to say.

Signature

Enough is enough.  It is /not/ a requirement that someone must google
relentlessly for an answer before posting in usenet.  Newsgroups are
for discussions.  Discussions do /not/ necessitate prior research.  If
you are bothered by someone asking a question without taking time to
look something up, simply do not respond.

Virgil Green - 29 Apr 2005 20:56 GMT
> We had what I consider to be an extremely odd occurrence this morning. A
> class that has not been changed for over 2 years appears to have failed to
[quoted text clipped - 52 lines]
>
> All thoughts appreciated.

Never mind. I finally found the stacktrace printout. Indeed, the process
went through my option 2 described above.

Signature

Virgil



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.