2 Replies Latest reply on Apr 19, 2012 11:09 AM by csergiu77

    Large JMS Messages

      HAve the follwing scenario:

      Relative big jms messages around 10 - 20 MB but not so many less then 1500 were sent on a cluster of 2 weblogic server (10.3.2 ,file based persitence store , 3gb of ram each)

      We throttled the consumption by using only 5 consumers / server so to avoid a heavily memory consumption while consuming them.

      Problem appeared after the consumption of 1/3 of the messages from the queue when one after another the server stopped working

      both having

      Exception in thread "Thread-14" java.lang.OutOfMemoryError: Java heap space
           at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:39)
           at java.nio.ByteBuffer.allocate(ByteBuffer.java:312)
           at weblogic.store.io.file.StoreFile.expand(StoreFile.java:324)
           at weblogic.store.io.file.Heap.reserveSpace(Heap.java:305)
           at weblogic.store.io.file.Heap.multiWrite(Heap.java:438)
           at weblogic.store.io.file.FileStoreIO.flush(FileStoreIO.java:497)
           at weblogic.store.internal.PersistentStoreImpl.run(PersistentStoreImpl.java:638)
           at weblogic.store.internal.PersistentStoreImpl$2.run(PersistentStoreImpl.java:383)

      There was enough RAM so i wonder what might be the cause ?

      While putting the messages that arrive on the queue I assume until they end up on the filestore ..they are in teh memory ?

      Is there a buffer which might be configured for such cases ?

        • 1. Re: Large JMS Messages
          René van Wijk
          The notes provided here can maybe help you out: http://docs.oracle.com/cd/E24329_01/web.1211/e24390/jmstuning.htm#CHDIJEFE

          There are also some tips provided here (http://docs.oracle.com/cd/E24329_01/web.1211/e24390/jmstuning.htm#i1157046) for tuning
          JMS with large messages.

          "Another tuning parameter to consider is the chunk size. A chunk is a unit of memory that the WebLogic Server network layer, both on the client and server side, uses to read data from and write data to sockets. To reduce memory allocation costs, a server instance maintains a pool of these chunks. For applications that handle large amounts of data per request, increasing the value on both the client and server sides can boost performance. The default chunk size is about 4K. Use the following properties to tune the chunk size and the chunk pool size:

          weblogic.Chunksize – sets the size of a chunk (in bytes). The primary situation in which this may need to be increased is if request sizes are large. It should be set to values that are multiples of the network’s maximum transfer unit (MTU), after subtracting from the value any Ethernet or TCP header sizes. Set this parameter to the same value on the client and server.
          weblogic.utils.io.chunkpoolsize – sets the maximum size of the chunk pool. The default value is 2048. The value may need to be increased if the server starts to allocate and discard chunks in steady state. To determine if the value needs to be increased, monitor the CPU profile or use a memory/ heap profiler for call stacks invoking the constructor weblogic.utils.io.Chunk.
          weblogic.PartitionSize – sets the number of pool partitions used (default is 4). The chunk pool can be a source of significant lock contention as each request to access to the pool must be synchronized. Partitioning the thread pool spreads the potential for contention over more than one partition.
          For example, we can set the chunksize by using -Dweblogic.Chunksize=65536 on the command-line."

          When you are sending the large messages can you also monitor the respective JVM's to see how they are doing
          • 2. Re: Large JMS Messages
            Thanks..will start profiling on a similar enviroment ...but indeed defaults are not ok...and tuning is a must do.