Announcement Announcement Module
Collapse
No announcement yet.
MDP, DMLC, Websphere DMP JMS and cacheLevel Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • MDP, DMLC, Websphere DMP JMS and cacheLevel

    We're on Websphere 6.1 using Spring 2.5.5. Our application produces and consumes messages (so the processing can be done asynchronously). We use Spring Message Driven POJOs (MDPs) and the Websphere Default Message Provider (DMP) for a JMS broker (the one that comes with WAS out of the box - running in the System Integration Bus). The JVM running the IBM ME (Messaging Engine) utilizes a lot of CPU under load. We're looking at tunings to optimize this. We are testing various configurations of the cacheLevel (CACHE_AUTO, CACHE_NONE, etc.). CACHE_NONE has poor performance (big surprise!). The other settings work faster but have errors on JVM shut down.

    Here's the error we get:

    [9/23/09 15:25:16:366 CDT] 00000e31 LocalTranCoor W WLTC0033W: Resource jms/XXXXXQCF rolled back in cleanup of LocalTransactionContainment.
    [9/23/09 15:25:16:367 CDT] 00000e31 LocalTranCoor W WLTC0032W: One or more local transaction resources were rolled back during the cleanup of a LocalTransactionContainment.

    The Javadoc on CACHE_AUTO is vague. What cache level does it pick? It indicates it's based on whether you're using your own transaction manager. We've tried it with and without. Any suggestions are appreciated along with tips on getting this to work and perform well with this combination of technologies. Thanks!

  • #2
    [9/23/09 15:25:16:366 CDT] 00000e31 LocalTranCoor W WLTC0033W: Resource jms/XXXXXQCF rolled back in cleanup of LocalTransactionContainment.
    [9/23/09 15:25:16:367 CDT] 00000e31 LocalTranCoor W WLTC0032W: One or more local transaction resources were rolled back during the cleanup of a LocalTransactionContainment.
    Some Googling of the error codes you're seeing seems to indicate a problem with transactions not being committed. I even found a reference to a patch for WAS 6.0.0.2 that cleared up the problem for one person:

    http://www.coderanch.com/t/78076/Web...e-rollback-WAS

    The Javadoc on CACHE_AUTO is vague. What cache level does it pick? It indicates it's based on whether you're using your own transaction manager. We've tried it with and without.
    If you're using a transaction manager then CACHE_NONE is used, otherwise CACHE_CONSUMER is used. This is because external transaction managers typically require that resources be refreshed for each transaction.

    Transaction performance can be improved by using the Spring JmsTransactionManager with the sessionTransacted property set to true on the DefaultMessageListenerContainer. This enables the use of JMS local transactions as well as the CACHE_CONSUMER property to be enabled on the DefaultMessageListenerContainer, both of which can improve performance. Just bear in mind that the use of JMS local transactions only covers the invocation of the message listener. Still, this solution is common and quite adequate.

    Bruce

    Comment

    Working...
    X