[WebLogic crash] Stack overflow error not notified

Question

I want to notify an error that occurred to me; this is the working
environment:
- Weblogic 5.1 SP10
- Windows2K SP2 / Solaris --> tested on both systems
- JBuilder 5 enterprise / JDK 1.3 and JDK 1.2.2 --> tested in
both environments
- session beans container managed ( incriminated components :-) )
Last week I made a mistake with cut and paste in my code, resulting in
a block of code like this:
public static final void rollback() {
try {
rollback(); // this instead of something like
// sessionContext.setRollbackOnbly()
} catch(Exception ex) {}
This method, that is included in the root class from which all my
session beans are derived, is called whenever an excepion occurs in my
session methods; a generic session method in my own implementation is
something like this:
public void performAction( <Action> data ) throws
<MY_EXCEPTION_TYPES>{
boolean bOperationSuccess = false;
try {
<do_something>
bOperationSuccess = true;
} catch (<HANDLED_EXCEPTION> ex) {
...... // handle errors and rethrow if necessary a new owner's
exception
} finally {
if (!bOperationSuccess ) rollback;
The result of this error has been a systematic crash of Weblogic,
without any log or message on standard output (it has required more
time than necessary for me to retrieve the error since there was no
information about the cause of error). Is this an error of Weblogic
that intercepts all Throwable objects but handle only some of them or
is a problem related with JVM? Usually when JVM crash it create also
files like "hs_err_pidXXX.log", but I've not found such a similar
file, so I suppose it's not a crash of JVM.
I've tried to test the same function with a "Test" class like this:
class Test {
public static final void rollback() {
try {
rollback(); // this instead of something like
// sessionContext.setRollbackOnbly()
} catch(Exception ex) {}
public static void main(String argv[]) {
try { <something> } finally { rollback(); }
and the result has been correctly a "StackOverflowError" (no crash of
JVM).
Obviously it is due to a stupid error of mine ( damn cut & paste :-)
), but my question is: can be this a warning for you about how certain
type of errors are handled by weblogic or is this a not systematic and
so no relevant problem ?
In the former case, can you remove this problem in future releases?
It could be really problematic the crash of a server in a production
environment
(I'm working for a important bank, and here I can't allow the system
to have systematic crashes, even if the situations that may cause
crash are rare and strange, since that cause is systematic and could
cause the crash of all the servers in the cluster in a chunk of
seconds if the end-user repeat the critical operation more times).
Obviously my particular error can be easily discovered in a testing
environment, but what could it happen if the loop was caused only by a
particular method in particular condition? It should never cause the
crash of the server.
Maybe some Weblogic settings can help me on this?
Thanks in advance for any advice,
Massimiliano Mercogliano.

Answer 1

That is the result of a bug in HotSpot. If you use
"-classic -Djava.compiler=" to use the interpreter, you will get the correct
exception etc.
Peace,
Cameron Purdy
Tangosol Inc.
Tangosol Coherence: Clustered Coherent Cache for J2EE
Information at http://www.tangosol.com/
"Massimiliano Mercogliano" <[email protected]> wrote in message
news:[email protected]...
I want to notify an error that occurred to me; this is the working
environment:
- Weblogic 5.1 SP10
- Windows2K SP2 / Solaris --> tested on both systems
- JBuilder 5 enterprise / JDK 1.3 and JDK 1.2.2 --> tested in
both environments
- session beans container managed ( incriminated components :-) )
Last week I made a mistake with cut and paste in my code, resulting in
a block of code like this:
public static final void rollback() {
try {
rollback(); // this instead of something like
// sessionContext.setRollbackOnbly()
} catch(Exception ex) {}
This method, that is included in the root class from which all my
session beans are derived, is called whenever an excepion occurs in my
session methods; a generic session method in my own implementation is
something like this:
public void performAction( <Action> data ) throws
<MY_EXCEPTION_TYPES>{
boolean bOperationSuccess = false;
try {
<do_something>
bOperationSuccess = true;
} catch (<HANDLED_EXCEPTION> ex) {
...... // handle errors and rethrow if necessary a new owner's
exception
} finally {
if (!bOperationSuccess ) rollback;
The result of this error has been a systematic crash of Weblogic,
without any log or message on standard output (it has required more
time than necessary for me to retrieve the error since there was no
information about the cause of error). Is this an error of Weblogic
that intercepts all Throwable objects but handle only some of them or
is a problem related with JVM? Usually when JVM crash it create also
files like "hs_err_pidXXX.log", but I've not found such a similar
file, so I suppose it's not a crash of JVM.
I've tried to test the same function with a "Test" class like this:
class Test {
public static final void rollback() {
try {
rollback(); // this instead of something like
// sessionContext.setRollbackOnbly()
} catch(Exception ex) {}
public static void main(String argv[]) {
try { <something> } finally { rollback(); }
and the result has been correctly a "StackOverflowError" (no crash of
JVM).
Obviously it is due to a stupid error of mine ( damn cut & paste :-)
), but my question is: can be this a warning for you about how certain
type of errors are handled by weblogic or is this a not systematic and
so no relevant problem ?
In the former case, can you remove this problem in future releases?
It could be really problematic the crash of a server in a production
environment
(I'm working for a important bank, and here I can't allow the system
to have systematic crashes, even if the situations that may cause
crash are rare and strange, since that cause is systematic and could
cause the crash of all the servers in the cluster in a chunk of
seconds if the end-user repeat the critical operation more times).
Obviously my particular error can be easily discovered in a testing
environment, but what could it happen if the loop was caused only by a
particular method in particular condition? It should never cause the
crash of the server.
Maybe some Weblogic settings can help me on this?
Thanks in advance for any advice,
Massimiliano Mercogliano.