8 Replies Latest reply on Jan 19, 2006 9:10 AM by adrian.brock

    WARN  [TransactionSynchronizer] ...  not the enlisting thre

    joergvf

      Hi,

      using JBossw 4.0.3 SP1, I'm getting the above warning, and I wonder what that should mean to me. Does anybody know whether I should care about it?

      Here's the stacktrace:

      19:19:49,548 WARN [TransactionSynchronizer] Thread Thread[http-0.0.0.0-8080-1,5,jboss] not the enlisting thread null
      java.lang.Exception: STACKTRACE
      at org.jboss.resource.connectionmanager.TransactionSynchronizer.enlisted(TransactionSynchronizer.java:144)
      at org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEventListener.enlist(TxConnectionManager.java:596)
      at org.jboss.resource.connectionmanager.TxConnectionManager.managedConnectionReconnected(TxConnectionManager.java:367)
      at org.jboss.resource.connectionmanager.BaseConnectionManager2.reconnectManagedConnection(BaseConnectionManager2.java:598)
      at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:465)
      at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:894)


      Thanks for any information,
      Jörg

        • 1. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting

          It is possible you have found a problem with the logic, since this code is new.
          http://jira.jboss.com/jira/browse/JBAS-1935

          But this code only exists to workaround a "hole" in the spec
          when it comes concurrent enlistment of connections in a transaction.

          So unless you are seeing the WARN accompanied with an ERROR
          that says it cannot enlist the resource it isn't going to cause you a problem.

          Of course concurrent use a transaction might not be what you intended
          or what you are doing anyway. ;-)

          • 2. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting

            The actual code works as follows, so maybe you can spot the gap in the logic?

            Every transaction has a TransactionSynchronizer synchronization
            that accumulates "I want to enlist these resources".

            To avoid the "race" of two threads trying to enlist the same resource at the same time,
            it elects one of the threads to do any outstanding enlist requests:

             // Perform the enlistment(s)
             ArrayList unenlisted = synchronizer.getUnenlisted();
             if (unenlisted != null)
             {
             try
             {
             for (int i = 0; i < unenlisted.size(); ++i)
             {
             TransactionSynchronization sync = (TransactionSynchronization) unenlisted.get(i);
             if (sync.enlist())
             synchronizer.addEnlisted(sync);
             }
             }
             finally
             {
             synchronizer.enlisted();
             }
             }
            


            So it can't even get to that WARN unless the thread was elected as the enlisting thread
            AND there are outstanding enlistments, done here:
             synchronized ArrayList getUnenlisted()
             {
             Thread currentThread = Thread.currentThread();
             while (enlistingThread != null && enlistingThread != currentThread)
             {
             boolean interrupted = false;
             try
             {
             wait();
             }
             catch (InterruptedException e)
             {
             interrupted = true;
             }
             if (interrupted)
             currentThread.interrupt();
             }
             ArrayList result = unenlisted;
             unenlisted = null;
             if (result != null)
             enlistingThread = currentThread;
             return result;
             }
            


            The WARN occurs in a "sanity check" when the finally blocks tries to say
            "I am no longer the enlisting thread"
            but the TransactionSynchronizer says "you weren't anyway!".

             /**
             * This thread has finished enlisting
             */
             synchronized void enlisted()
             {
             Thread currentThread = Thread.currentThread();
             if (enlistingThread == null || enlistingThread != currentThread)
             {
             log.warn("Thread " + currentThread + " not the enlisting thread " + enlistingThread, new Exception("STACKTRACE"));
             return;
             }
             enlistingThread = null;
             notifyAll();
             }
            


            • 3. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting

              I'd also suspect the usual broken JVM/c-library/OS combinations
              with broken threading/locking primitives.
              e.g.
              * Sun operating systems with the wrong patch level
              * Incorrect/Unsupported glibc versions
              * Using Redhat's broken backport of NPTL to Linux 2.4.x

              But since you provide very little information beyond the stacktrace it is hard to say.

              • 4. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting
                joergvf

                This is with Windows XP and JDK 1.5_05, and I'm not concurrently using the same UserTransaction or something.

                Sorry I don't have time at the moment to try to find the gap in the logic here, I might look at it in the debugger when those warnings in the log get on our nerves overly ;)

                • 5. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting
                  joergvf

                  I forgot to mention that the warning is followed by another one:

                  2005-12-15 15:38:01,628 WARN [org.jboss.resource.connectionmanager.TxConnectionManager] Prepare called on a local tx. Use of local transactions on a jta transaction with more than
                  one branch may result in inconsistent data in some cases of failure.

                  What do I have to think of this one?

                  • 6. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting

                    Your second warning is an FAQ

                    • 7. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting
                      joergvf

                      What I'm doing is that I look up the ManagedConnectionFactory once, and then use it from different threads to obtain a connection. What then happens is that different threads receive handles to the same ManagedConnection object. As I don't know much of the JCA spec, I can't tell whether that is legal or not, and where the source of this behaviour might even be. However, concerning this, I've been told the following by the guys who maintain the JCA adapter I'm using (which was originally written by David Jencks):

                      You may ask JBOSS why the ManagedConnect(thread 1) was given to MCF.matchManagedConnection in thread 2 while the user requested a new ManagedConnection (getConnection())

                      You have

                      Thread 1
                      MCF (1)
                      MC (2)

                      Thread 2
                      MCF (1)
                      MC (2) <-- why?
                      Sounds like this could be related to the warning, what do you think?

                      • 8. Re:  WARN  [TransactionSynchronizer] ...  not the enlisting

                         

                        "joergvf" wrote:

                        You may ask JBOSS why the ManagedConnect(thread 1) was given to MCF.matchManagedConnection in thread 2 while the user requested a new ManagedConnection (getConnection())

                        You have

                        Thread 1
                        MCF (1)
                        MC (2)

                        Thread 2
                        MCF (1)
                        MC (2) <-- why?
                        Sounds like this could be related to the warning, what do you think?


                        Show me how that conclusion was reached!

                        I work from facts, not ungrounded assertions.