glassfish
  1. glassfish
  2. GLASSFISH-15558

Caching JMS session in a session bean causes errors when invoked by a MDB when under load

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.1_b37
    • Fix Version/s: 4.1
    • Component/s: jms
    • Labels:
      None

      Description

      This issue was originally reported by a user on the GlassFish developer list. Here is the thread:
      http://www.java.net/forum/topic/glassfish/glassfish/jms-and-transaction-issue

      The issue can be summarised as follows: a MDB consumes a message from an inbound queue, updates a database then invokes a session bean which sends a message to an outbound queue. If 40 messages are placed on the inbound queue then we see a variety of messages in the server log (see that thread), including this one:

      625+0000|SEVERE|glassfish3.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=36;_ThreadName=Thread-1;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:950872495901869318 and onePhase:false due to Unknown JMSService server error ERROR: com.sun.messaging.jmq.jmsserver.util.BrokerException: Bad transaction state transition. Cannot perform operation COMMIT_TRANSACTION(46) (XAFlag=0x0:TMNOFLAGS) on a transaction in state COMPLETE(4).|#]

      The error occurs ONLY if the session bean caches its JMS connection, session and producer in a field of the bean. This is valid, though it is contrary to the conventional practice which is to create the connection, use it, and close the connection every time the session bean is invoked. If these objects are not cached then this bug is NOT seen. This bug therefore has a workaround.

      The issue can be reproduced using JMS only (i.e. not using a database), though to see exactly the same errors as the user reported it is necessary to force the use of two-phase commits.

      A simple NetBeans application is attached which demonstrates the issue. This consists of a Enterprise Application "TransactionTests" which is composed of a ejb application "TransactionTests-ejb" and a web application "TransactionTests-war".

      Steps to reproduce:

      1. Install the latest version of GlassFish 3.1 (I used build 37)
      2. Before starting GlassFish, edit domain.xml to set the JVM option -Dimq.jmsra.isSameRMAllowed=false . This is needed to force two-phase transactions to be used. (If this is not done the application will still fail but you will get different errors).
      3. Use NetBeans to build the application (which is an ear cotaining an ejb and a web app) and deploy it in GlassFish.
      4. Visit http://localhost:8080/TransactionTests-war/ and click on "Run MDB Test 1". This causes a servlet to send 40 messages to the inbound queue.
      5. Inspect the server log for errors

        Activity

        Hide
        Nigel Deakin added a comment -

        @jthoennes - Yes, please file an issue with Oracle support as you suggest. There is a separate engineering team to resolve customer issues, so raising it with support increases the resources available to address this issue.

        Show
        Nigel Deakin added a comment - @jthoennes - Yes, please file an issue with Oracle support as you suggest. There is a separate engineering team to resolve customer issues, so raising it with support increases the resources available to address this issue.
        Hide
        Nigel Deakin added a comment -

        I have reviewed this bug for 3.1.1 and decided not to fix it in that version for the following reasons:

        • This bug is in older versions of GlassFish (including GlassFish 2.1.1) and so is not a regression
        • There is a workaround (see earlier comment)
        • The fix would require significant changes to the XAResource implementation classes in the JMSRA resource adapter. In addition to the work involved it would require a lot of testing to be sure that it does not introduce a regression. 3.2 will have much more testing than 3.1.1 and so, given that this is an old bug which has a workaround, I would like to defer fixing this bug until 3.2 so it can be properly tested.

        Removing the 3_1_1-review tag.

        @jthoennes - note that if you raise this issue with Oracle support this will still be reviewed by Oracle sustaining.

        Show
        Nigel Deakin added a comment - I have reviewed this bug for 3.1.1 and decided not to fix it in that version for the following reasons: This bug is in older versions of GlassFish (including GlassFish 2.1.1) and so is not a regression There is a workaround (see earlier comment) The fix would require significant changes to the XAResource implementation classes in the JMSRA resource adapter. In addition to the work involved it would require a lot of testing to be sure that it does not introduce a regression. 3.2 will have much more testing than 3.1.1 and so, given that this is an old bug which has a workaround, I would like to defer fixing this bug until 3.2 so it can be properly tested. Removing the 3_1_1-review tag. @jthoennes - note that if you raise this issue with Oracle support this will still be reviewed by Oracle sustaining.
        Hide
        jthoennes added a comment -

        Filed Oracle Service Request "SR 3-3705874175: Resolve GLASSFISH-15558 for Glassfish 3.1.1" for this issue.

        Show
        jthoennes added a comment - Filed Oracle Service Request "SR 3-3705874175: Resolve GLASSFISH-15558 for Glassfish 3.1.1" for this issue.
        Hide
        marina vatkina added a comment -

        Re EJB container behavior: In our current implementation, bean instances are returned to pool at the end of method invocation. If we were to to delay it till the termination of tx, we would need more instances because transaction can last much longer than a single method invocation.

        Show
        marina vatkina added a comment - Re EJB container behavior: In our current implementation, bean instances are returned to pool at the end of method invocation. If we were to to delay it till the termination of tx, we would need more instances because transaction can last much longer than a single method invocation.
        Hide
        Nigel Deakin added a comment -

        Adding 3_1_2-exclude tag. Excluding from 3.1.2 for the same reason it was excluded from 3.1.1 (see my comment above).

        Show
        Nigel Deakin added a comment - Adding 3_1_2-exclude tag. Excluding from 3.1.2 for the same reason it was excluded from 3.1.1 (see my comment above).

          People

          • Assignee:
            Nigel Deakin
            Reporter:
            Nigel Deakin
          • Votes:
            3 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated: