Atomikos Forum

Hello,

We have problems with high memory usage during transactions. We wanted to process 172000 transactions in batch and we split these transactions up into batches of 500. When we ran this the memory kept creeping up in an alarming high rate. With the use of MAT64 we found the problem to be in the FileLogStream class and with the ooutput_ attribute specially. This is uses ObjectOutputStream class and it looks like this Java class is keeping a pointer to the objects written in the stream, so the garbage collector can not clean it up. I have found a few bug reports within the Sun JDK which are interesting;

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6525563
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4363937

The problem can be workaround by reset()-ing of closing the ObjectOutputStream and Sun does not seem in a hurry to do anything about it.

Please let me know you view on this 'problem'. Our workaround is to switch off com.atomikos.icatch.enable_logging altogether.

Kind regards,

Edwin

Will check - thanks.

Hi,

I checked this in the code, and AFAIK this should be reset every time there is a checkpoint.

Question: does setting the com.atomikos.icatch.checkpoint_interval to a lower value help?

Thanks

Our amount of selects and updates are very high during these 176000 transactions. So within minutes we are on about 2.5Gb of JVM memory and still counting. All the memory is being eaten by this JVM bug/feature. Our application is very happy with out 350MB but needs more than 2.5GB to finish (we never tried to find out).

You could bypass this bug by using the ObjectOutputStream to a ByteArrayOutputStream and then write the object to this bytearray and close the ObjectOutputStream and write the bytearray directly to a output stream.

Kind regards,

Edwin