4 Replies Latest reply on Mar 17, 2008 5:05 AM by Tina Muehle

    Starting a new JVM within a transaction marks it aborted

    Tina Muehle Newbie

      Hi,

      we are using JBOSS 4.2.2ga with EJB 3.0. The default transation attribute is 'Required'. The user can upload a video and the meta information (like duration, size etc) will be extracted using fobs4jmf. Sometimes the video is corrupt, causing JBOSS to crash.

      To prevent this we outsourced the extraction process by starting a new jvm with creation of a ProcessBuilder instance. So if this jvm crashes, JBOSS remains intact.

      However, now when the method for the extraction process is invoked, we get the following Exception:

      javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
      java.lang.RuntimeException: javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
       at org.jboss.aspects.tx.TxPolicy.handleEndTransactionException(TxPolicy.java:198)
       at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:180)
       at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
       at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
       at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
       at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
       at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
       at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
       at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
       at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
       at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
      Caused by: javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
       at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1401)
       at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
       at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
       at org.jboss.aspects.tx.TxPolicy.endTransaction(TxPolicy.java:175)
       at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:87)
       at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
       at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
       at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
       at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
       at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
       at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
       at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
       at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
       at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
       at org.jboss.remoting.Client.invoke(Client.java:1634)
       at org.jboss.remoting.Client.invoke(Client.java:548)
       at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:67)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
       at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
       at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
       at $Proxy0.importMedium(Unknown Source)
      
      


      Any idea what I have to do?

      Tina

        • 1. Re: Starting a new JVM within a transaction marks it aborted
          Vicky Kak Master

           

          "tina99" wrote:

          Any idea what I have to do?
          Tina

          I don't think Transaction are propagated across the processes , even across the Threads .
          Thread assoications are linked with ThreadLocal so it would not be passed to another Thead/Process .




          • 2. Re: Starting a new JVM within a transaction marks it aborted
            Andrew Dinn Master

             


            To prevent this we outsourced the extraction process by starting a new jvm with creation of a ProcessBuilder instance. So if this jvm crashes, JBOSS remains intact.


            You *must* run the EJB call inside an application server. Creating a separate JVM to run the EJB method will not work unless that JVM is used to boot another JBoss instance. This achieves little or nothing because the EJB call can still crash the new JBoss instance. Besides, if you need two JBoss instances you will find it much easier to manage them by starting them from the command line and using a script to automate the process.

            Personally, I think you would be much better off fixing the error in your EJB code which causes JBoss to crash.


            • 3. Re: Starting a new JVM within a transaction marks it aborted
              Tina Muehle Newbie

               

              "vickyk" wrote:
              "tina99" wrote:

              Any idea what I have to do?
              Tina

              I don't think Transaction are propagated across the processes , even across the Threads .
              Thread assoications are linked with ThreadLocal so it would not be passed to another Thead/Process .


              I just figured out that the exception has nothing to do with the start of the external process. By the way I do not even need the transaction propagated to the other process so I wondered what happened here.

              Now I commented out the call to the external process and I still getting the above exception. In the log I found this:


              [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_36] - BasicAction.End() - prepare phase of action-id -53e3ca3f:c061:47de2e24:b9 failed.
              09:39:47,605 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_38] - Action Aborting
              09:39:47,605 WARN [logger] XAOnePhaseResource.rollback(< 131075, 28, 26, 1--53e3ca3f:c061:47de2e24:b9-53e3ca3f:c061:47de2e24:bd >) wrong xid in rollback: expected: null, got: < 131075, 28, 26, 1--53e3ca3f:c061:47de2e24:b9-53e3ca3f:c061:47de2e24:bd >
              09:39:47,611 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_54] - Top-level abort of action -53e3ca3f:c061:47de2e24:b9 received TwoPhaseOutcome.FINISH_ERROR from <ClassName:RecordType.LASTRESOURCE>


              Why do I have a wrong xid? Is this not handled transparently by JBoss?

              Tina

              • 4. Re: Starting a new JVM within a transaction marks it aborted
                Tina Muehle Newbie

                 

                "adinn" wrote:

                To prevent this we outsourced the extraction process by starting a new jvm with creation of a ProcessBuilder instance. So if this jvm crashes, JBOSS remains intact.


                You *must* run the EJB call inside an application server. Creating a separate JVM to run the EJB method will not work unless that JVM is used to boot another JBoss instance. This achieves little or nothing because the EJB call can still crash the new JBoss instance. Besides, if you need two JBoss instances you will find it much easier to manage them by starting them from the command line and using a script to automate the process.

                Personally, I think you would be much better off fixing the error in your EJB code which causes JBoss to crash.


                Sorry for the misunderstanding. I do not start separate jvm to invoke an ejb method. The jvm is created within the ejb method. This new jvm process creates an instance of a java media framework processor to extract the meta information of a video file. The information is captured in the output stream so I can get the data and go on in the ejb method.

                This is just a workaround because the jmf is quite buggy and cannot handle all file formats properly which causes severe errors sometimes resulting in a crash for jboss.