Static initilizer failed to execute?

[Virgil Green]

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.

 

[John C. Bollinger]

Virgil Green wrote:

[...]

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.

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.

 

[Virgil Green]

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.

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

 

[Virgil Green]

Virgil Green wrote:

[...]

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.

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).

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.

 

[Thomas G. Marshall]

John C. Bollinger coughed up:

Virgil Green wrote:

[...]

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.

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.

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.


--
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.