3 Replies Latest reply on May 6, 2002 3:14 AM by danmartin

    DEADLOCK with JBoss 2.4.4

    danmartin

      Hi all,
      we're having a critical deadlock problem with JBoss 2.4.4, using CMP beans and Oracle 8 DB.

      Our bean descriptors defines three different transaction levels:
      1) list methods have Supports transaction:
      ...
      <method-name>list*</method-name>
      ....
      <trans-attribute>Supports</trans-attribute>

      2) get methods have Supports transaction:
      ...
      <method-name>get*</method-name>
      ....
      <trans-attribute>Supports</trans-attribute>

      3) all other methods have Required transaction:
      ...
      <method-name>*</method-name>
      ....
      <trans-attribute>Required</trans-attribute>

      We implement some long time tasks with Session Beans that access EJB interfaces with Container transaction.
      During these tasks, Entity Beans send notifications to client, via JMS, of state changes: each time a client receives one message, it gets the Entity Bean state using the appropriate remote interface. When the client does it, the whole application gets stuck: it seems that the client locked one DB table to get data, but the server procedure running also needs this table to complete the procedure.
      This may sound strange, because the client has only to read data from the table and, once it gets the lock, it should make the job, but it seems waiting for something else, maybe to read another table locked by the server procedure.

      Furthermore, other unexpected waits happens, when two clients work contemporary. Not so good, ...

      This didn't happen with JBoss 2.4.1 (we used a Required transaction for all the EJB's and worked fine)
      We must use 2.4.4 because of other bugs fixed in this release.

      Any help or suggestions?

      Thanks in advance,
      Daniele

        • 1. Re: DEADLOCK with JBoss 2.4.4
          shortpasta

          Same problem here..... 2.44 & mySql w InnoDb

          • 2. Re: DEADLOCK with JBoss 2.4.4
            michel1

            We experienced something similar. In our case, it turned out to be an overflow of the JMS queue. When the JMS queue is full, the EJB sending the notification cannot deliver the JMS message, so it blocks. The clients that respond to the messages delivered by the JMS queue required a resource that was held by one the of message senders. So they blocked. Because of this, no slots become available in the JMS queue, so we experienced a nice deadlock.

            If you have the same kind of deadlock, try to measure when it occurs: in our case, it occurred under heavy load and always with *exactly* the same number of transactions occurring before the deadlock.

            Solution: seriously boost the number of JMS slots in the $jboss/conf/standardjboss.xml. See below for an example, you need to modify the 1000 field.


            <container-configuration>
            <container-name>Standard Message Driven Bean</container-name>
            <call-logging>false</call-logging>
            <container-invoker>org.jboss.ejb.plugins.jms.JMSContainerInvoker</container-invoker>
            <container-interceptors>
            org.jboss.ejb.plugins.LogInterceptor
            org.jboss.ejb.plugins.SecurityInterceptor
            <!-- CMT -->
            org.jboss.ejb.plugins.TxInterceptorCMT
            org.jboss.ejb.plugins.MetricsInterceptor
            org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor
            <!-- BMT -->
            org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor
            org.jboss.ejb.plugins.MessageDrivenTxInterceptorBMT
            org.jboss.ejb.plugins.MetricsInterceptor
            </container-interceptors>
            <instance-pool>org.jboss.ejb.plugins.MessageDrivenInstancePool</instance-pool>
            <instance-cache></instance-cache>
            <persistence-manager></persistence-manager>
            <transaction-manager>org.jboss.tm.TxManager</transaction-manager>
            <container-invoker-conf>
            DefaultJMSProvider
            StdJMSPool
            1000
            1
            True
            </container-invoker-conf>
            <container-pool-conf>
            100
            10
            </container-pool-conf>
            </container-configuration>

            • 3. Re: DEADLOCK with JBoss 2.4.4
              danmartin

              Thanks Michel,
              now the problem seems fixed at 80%
              We still have a problem when, during a server long-time task, a different client makes a call on one EJB involved with this task.
              Sometimes seems that the second client locks the EJB table when making the call so, when the first task needs to access the same EJB to store new data, the container immediately throws a deadlock exception and cmp attributes are not updated.
              As soon as I can, I will provide a JBoss stack trace to add some info about it.

              Thanks a lot for the help,
              Daniele