• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

J2ee memory issue

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
I'm having a problem that appears to be related to memory, but I'm not sure. It appears that when I do a Session.commit() to commit a jms message after I read it using BytesMessage.readBytes(), the J2ee server takes a lot of cpu and takes a while to actually commit the message. It appears to be doing this while the j2ee server has about 64 megs of ram allocated to it. I'm not sure what the Session.commit() function is actually doing behind the scenes, but I do know that it is supposed to delete the message off the jms queue. Anyway, is there a way to allocate more memory for the j2ee server. I have checked the documentation (it is version 1.3.1), and I can't seem to find anything in the docs or online.

Regards,
Gordon
 
Gordon Glas
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok... I no longer think it's a memory issue, because it has happened while using more than 64mb. I tried various combinations of how my QueueSession was created. In other words, transacted vs non-transacted, auto-acknowledge vs client-acknowledge, and persistant vs non-persistant. But all combinations seem to give me the same results: once I commit the message (or when I simply call receive() while using non-transacted messages), the j2ee server takes almost all cpu time, and after about 5 minutes it finally writes out the jms messages to the hard drive under J2EE_HOME/repository/HOST_NAME/db...etc. Once it's finally done writing out the jms messages, the call to commit() in my java app returns and continues to process. It's almost as if the commit() or acknowledgement of the message is temporarily locking up the j2ee server. It still works, but 5 minutes for such a small jms message (about 800kb) seems rediculous. I have plenty of ram available, so I'm not sure what the j2ee server is doing. Anyone have any ideas? Again, i'm using j2ee 1.3.1, so I will try 1.4 in the meantime to see if that helps.

Thank you,
Gordon
[ October 21, 2004: Message edited by: Gordon Glas ]
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gordon,
I don't think I have yet got a full grasp of the scenario that you have been experiencing. This problem that you might be experincing could be specific to an Application Server. Since you are using non-transacted messageds, use a JMS Connection factory that is configured NOT to use XA. If you happen to be using Weblogic this URL (http://e-docs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#jms_connection_factories_config) might come in handy.

Also, to increase the available memory for your J2EE server, look for the startup scripts for the server. When the VM is created (using the 'java' command, check the following arguements to the executable -Xms and -Xmx.
ms - denotes starting heap size and mx- denotes max heap size that the VM can grow to. If you have a lot of ohysical memory available say a 512 MB RAM. try java -Xms 256 -Xmx 256.

Regards
pradeeP
 
reply
    Bookmark Topic Watch Topic
  • New Topic