Hi folks,
I'm seeing an odd situation where I'm getting a
java.lang.OutofMemoryError and a core dump from the JRE (this is
Solaris_JRE_1.1.6_04). Is there any sort of known bug that might
cause this? Here's the actual error message and some details about
the situation where it occurs:
-beginning-of-log-excerpt---------------------------------------------
java.lang.OutOfMemoryError
at sun.rmi.transport.tcp.TCPTransport.newListener(Compiled Code)
at sun.rmi.transport.tcp.TCPTransport.run(Compiled Code)
at java.lang.Thread.run(Compiled Code)
SIGSEGV 11* segmentation violation
si_signo [11]: SIGSEGV 11* segmentation violation
si_errno [0]: Error 0
si_code [1]: SEGV_MAPERR [addr: 0xe2042024]
stackbase=E9D11D6C, stackpointer=E9D11604
Full thread dump:
-end-of-log-excerpt---------------------------------------------------
The log actually ends here, before any info in the 'full thread
dump' is printed.
The context is a JRE running a java server that takes RMI
requests from several servlets running under a servlet engine on a
different machine.
I've tried starting the JRE with -mx64M and -ms64M, and I have
memory monitoring code that shows there's plenty of memory available.
The monitoring from just before the core dump said:
Allocated: 4194296
Available: 3703120
Difference: 491176
Consistently, before each core dump I had about a dozen
exceptions thrown. None of them are show-stoppers - my code just logs
them and continues to process new requests.
In most of the cases, about half a dozen times so far, the
exceptions are generated by MQSeries messaging errors. The calls to
the MQSeries API in question are wrapped with try/catch statements
that clean up the queues and disconnect MQ. In a couple cases they
were FileNotFound exceptions (generated by trying to open a new file
in a full partition).
In all of the cases, the code does try/catch, prints the
exception to the log, and returns a valid default value. I have
similar situations elsewhere in the code, where I catch an different
exception and return a valid default value. I haven't had any problem
with core dumps from these, but then again they don't tend to occur in
great numbers at the same time.
The error comes from somewhere in the TCP/RMI area of the
libraries, so maybe something is going wrong with the exception
generation holding things up, and requests start stacking up until
rmiregistry or something has too much to keep track of? Maybe it's
time to dig through the RMI registry docs and see if there's any sort
of API call to monitor this?
Steven J. Owens
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
