Menu
▾
▴
#1536 Memory leak and odd JMS Errors
I am in the process of trying to track down some
memory leaks in my jboss-based application. Along the
way, I ran into something that appears to be a bug.
Windows XP
j2sdk1.4.2_01
JBoss3.2.2RC4
Take the 'jboss-3.2.2RC4-src.tgz' from sourceforge and
build it.
Uncomment the 'rem set JAVA_OPTS=%JAVA_OPTS% -
Xms128m -Xmx512m' line in run.bat.
Copy the .sar file from the attached zip into the
default/deploy directory.
Start the JBoss server.
The memory usage never levels off. However, the
speed at which it climbs varies from run to run. I've
seen the server hit 300mb of memory (taskmanager)
usage in 40 minutes or take 90 minutes to hit the 200mb
mark.
The attached sar contains an mbean that sends 10
TextMessages to the 'queue/A' JMS queue every 100
milliseconds.
The attached zip includes a log file from one of my
runs. Please note the errors in the log file. The
frequency with which they appear *seems* to coincide
with the amount of memory used.
I've also included the source to the mbean.
Log & Src/Sar that exhibits problem
Logged In: YES
user_id=9459
I haven't tried your test.
The errors in your log shows a Bind exception when the server
tries to connect back to the client.
Since this is a client socket attaching to server socket
inside the
JMS client, I can only assume it is the client port that
cannot be bound.
This is a problem at the OS level (or maybe the VM).
It is assigning your client socket a port that is already in
use?
Incidently, since this is in the same VM, why are you using
java:/ConnectionFactory (method calls)
instead of OIL which uses two (local) sockets?
Regards,
Adrian
Logged In: YES
user_id=568636
Switching out the Hypersonic ConnectionManager for one
that stores messages in SQL2k appears to fix the problem. I
also seem to be getting much fewer bind exceptions as well.
Since getting rid of Hypersonic is also on my list of tasks, I'm
fine with this solution.
I'm using java:/ConnectionFactory just because every
example I've ever seen uses that. Do I just change that to
java:/OIL2ConnectionFactory to switch to OIL?
Logged In: YES
user_id=175228
You are not using the "java:/ConnectionFactory" binding, you
are using the "ConnectionFactory" binding. This is looking
up the OIL version rather than the in vm socketless
transport. Use
InitialContext ctxt = new InitialContext();
QueueConnectionFactory connFactory =
(QueueConnectionFactory)ctxt.lookup("java:/ConnectionFactory")
to access the in vm transport.
Logged In: YES
user_id=9459
I have enabled the ReadTimeout on OIL
I added this to an earlier version of 3.2, but didn't enable it.
It is possible for the server side of OIL to not notice a
client has
vanished without it.
This will block a socket.
Regards,
Adrian