12 Replies Latest reply: Aug 13, 2012 4:02 AM by Baerbel Lindner RSS

Deployment on linux leads to transaction problems

Baerbel Lindner Newbie

Hello,

we are porting a greater application from JBoss 5.1 to JBoss 7.1.1 Final

Our application includes several deployments (26). We are deploying several EJBs, web services.

 

The Deployment on several Windows systems were successful.

 

On our Linux system (SLES 11) we are getting deploment errors and JBoss does not start.

15:10:52,285 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a85b80:662c2036:4feb051b:8 in state  RUN

15:10:52,299 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffffc0a85b80:662c2036:4feb051b:8 invoked while multiple threads active within it.

15:10:52,301 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffffc0a85b80:662c2036:4feb051b:8 aborting with 1 threads active!

15:10:52,311 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffc0a85b80:662c2036:4feb051b:8

15:10:52,323 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a85b80:662c2036:4feb051b:9 in state  RUN

15:10:52,365 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffffc0a85b80:662c2036:4feb051b:9 invoked while multiple threads active within it.

15:10:52,365 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffffc0a85b80:662c2036:4feb051b:9 aborting with 1 threads active!

15:10:52,368 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffc0a85b80:662c2036:4feb051b:9

15:11:02,449 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a85b80:662c2036:4feb051b:a in state  RUN

15:11:02,452 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffffc0a85b80:662c2036:4feb051b:a invoked while multiple threads active within it.

15:11:02,453 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffffc0a85b80:662c2036:4feb051b:a aborting with 1 threads active!

15:11:02,455 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffc0a85b80:662c2036:4feb051b:a

 

We have to kill the JBoss process.

 

Jboss 7.1.1 Final also starts on this Linux system in case of starting without our own deplyments and deploying the 26 war, jar, ear step by step using the management console.

 

We are only using the ExampleDS data source.

 

The Linux system has only 2 GB memory. We are starting JBoss 7.1.1 Final with the default configuration defined in standalone.sh and standalone.conf.

 

Any suggestions?

Thanks in advance.

 

Baerbel

  • 1. Re: Deployment on linux leads to transaction problems
    Frank Haverland Newbie

    We have the same problem on an older Windows System. Lokal deployment allways deploys all jars, wars and ears. But on the older system, the deployment process locks at the end. Sometimes it deploys successfull, so i think it's an deadlock.

     

    19:00:58,796 INFO  [org.hibernate.ejb.Ejb3Configuration] (MSC service thread 1-4) HHH000204: Processing PersistenceUnitInfo [

              name: scm

              ...]

    19:00:59,593 INFO  [org.hibernate.service.jdbc.connections.internal.ConnectionProviderInitiator] (MSC service thread 1-4) HHH000130: Instantiating explicit connection provider: org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider

    19:00:59,625 INFO  [org.hibernate.dialect.Dialect] (MSC service thread 1-4) HHH000400: Using dialect: org.hibernate.dialect.Oracle10gDialect

    19:00:59,656 INFO  [org.hibernate.engine.jdbc.internal.LobCreatorBuilder] (MSC service thread 1-4) HHH000424: Disabling contextual LOB creation as createClob() method threw error : java.lang.reflect.InvocationTargetException

    19:00:59,656 INFO  [org.hibernate.engine.transaction.internal.TransactionFactoryInitiator] (MSC service thread 1-4) HHH000268: Transaction strategy: org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory

    19:00:59,656 INFO  [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (MSC service thread 1-4) HHH000397: Using ASTQueryTranslatorFactory

    19:01:01,390 DEBUG [de.it4logistics.scm.management.mbean.AmazonTerminKorrekturMBean] (MSC service thread 1-3) Start Korrektur Amazon Termine.

    19:06:01,296 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a808af:-32d6283b:4feb3c19:2a in state  RUN

    19:06:01,296 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012095: Abort of action id 0:ffffc0a808af:-32d6283b:4feb3c19:2a invoked while multiple threads active within it.

    19:06:01,296 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012108: CheckedAction::check - atomic action 0:ffffc0a808af:-32d6283b:4feb3c19:2a aborting with 1 threads active!

    19:06:01,296 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffffc0a808af:-32d6283b:4feb3c19:2a

    19:06:01,328 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a808af:-32d6283b:4feb3c19:2c in state  RUN

    19:06:01,328 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffffc0a808af:-32d6283b:4feb3c19:2d in state  RUN

  • 2. Re: Deployment on linux leads to transaction problems
    Baerbel Lindner Newbie

    Our deployment prozess on this linux system locks always but with different deployments. After exactly 5 minutes timeout the Transaction Reaper messages are shown.

    As akready mentioned, we are only using the default ExampleDS data source, no other datasources.

  • 3. Re: Deployment on linux leads to transaction problems
    Tomaz Cerar Master

    Hi,

     

    example DS is not meant to be used for anything else then demo/playground use cases.

    please configure proper datasource backed by some proper database and your issues should probably go away.

     

     

    --

    tomaz

  • 4. Re: Deployment on linux leads to transaction problems
    Frank Haverland Newbie

    In our case, we use a oracle database, but i have no active session or lock found. At deployment not all timers are initialized. Could it be depend on initializing different timers?

  • 5. Re: Deployment on linux leads to transaction problems
    Baerbel Lindner Newbie

    Hi Tomaz,

     

    thanks for your advice.

    I have removed all datasource definitions from standalone.xml: <subsystem xmlns="urn:jboss:domain:datasources:1.0"></subsystem> for test purpose.

     

    The same error messages occur and the deployment process is locking and his to be killed starting JBoss.

     

    JBoss is starting, working for about a minute, waiting for 5 minutes and showing the check timeout message. This behaviour is reproducible on our 2 linux test machines.

     

    14:19:21,592 INFO  [org.jboss.as.security] (ServerService Thread Pool -- 45) JBAS013101: Activating Security Subsystem

    14:19:24,399 INFO  [org.jboss.as.naming] (MSC service thread 1-2) JBAS011802: Starting Naming Service

    14:19:25,363 INFO  [org.jboss.ws.common.management.AbstractServerConfig] (MSC service thread 1-1) JBoss Web Services - Stack CXF Server 4.0.2.GA

    14:19:25,371 INFO  [org.jboss.as.connector] (MSC service thread 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final)

    14:19:25,755 INFO  [org.jboss.as.security] (MSC service thread 1-2) JBAS013100: Current PicketBox version=4.0.7.Final

    14:19:26,837 INFO  [org.jboss.as.mail.extension] (MSC service thread 1-2) JBAS015400: Bound mail session [java:jboss/mail/Default]

    ......

    14:20:31,099 INFO  [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /myApp/MyApp.html

    14:20:31,113 INFO  [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /FreeDownload

    14:20:31,186 INFO  [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/sv_www.html]] (MSC service thread 1-1) RedirectFilter:Initializing filter

    14:20:31,187 INFO  [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /myApp2.html

    14:25:31,321 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff7f000001:1875603f:4ff191d1:8 in state  RUN

    ...

    the deployment process has to be killed.

  • 6. Re: Deployment on linux leads to transaction problems
    Baerbel Lindner Newbie

    Hi,

     

    the deployment deadlock is now reproducible on 3 differnent linux machines. Our 26 deployments are started almost parellel from 2 threads (MSC service thread 1-1, MSC service thread 1-2), deployment is starting, no deployment is finished after some times all deployments seems to stop and after 5 minutes the check timeout messages are shown.

     

    We found a workaround, in using jboss-cli.sh for deploying: ./jboss-cli.sh --file=deploylist.cli

    deploylist.cli contains all deployments:

         connect

     

         deploy ../standalone/toDeploy/deploy1.war --force

         ...

         deploy ../standalone/toDeploy/deploy26.war --force

         quit

    All deployments are done in serial order. There are no deployment problems. I know that this is not the quickest way to deploy :-)

    Before jboss shutdown we undeploy all deployments (using jboss-cli.sh).  A side effect of these undeployments: almost all files in jboss/standalone/tmp/vfs are deleted. In case of simple jboss shutdown there seems to be problems: https://community.jboss.org/thread/201817?tstart=0

     

    Baerbel

  • 7. Re: Deployment on linux leads to transaction problems
    Scott Marlow Master

    For both of the above cases (on Windows or Linux), I would try two additional steps to find out why is taking longer than expected during deployment.  Taking Java thread dumps of the AS7 server instead a few times a minute (will give a few snapshots of what is going on). 

     

    If that doesn't give enough information to solve, enable TRACE logging for a few packages.  You could start with org.jboss.as.jpa, org.hibernate, com.arjuna (see example here.)  Then look at the server.log output to see what is occuring during the deployment.

  • 8. Re: Deployment on linux leads to transaction problems
    Tomaz Cerar Master

    Hi,

     

    can you try to reproduce this on nightly build https://community.jboss.org/thread/167590 as there ware some changes in this area since 7.1.1

    and if/when problem occures please do what Scott has suggested.

    java thread dump would really must see to know what thread is locking up the server

    also TRACE logging would help.

     

     

    --

    tomaz

  • 9. Re: Deployment on linux leads to transaction problems
    Baerbel Lindner Newbie

    Hello,

     

    in the meantime we have tried the latest nightly builds but the deployment deadlock still remains.

     

    After analyzing java thread dumps from the deadlock situation we identified some potential problematic code and changed it.

    But still one problem remains:

    we have a Singleton EJB that reads some property files at init time. The Singleton is annotated with

    @Startup

    @Lock(LockType.READ)

     

    Additionally we are using servlet filter that are used from different war and jar projects. These filter are trying to read properties delivered from our Singleton EJB.

     

    The deadlock occurs during the deployment of the war and jars that are using the filter. Our Singleton EJB isn't even loaded in the moment of the deadlock, the PostConstruct method has no chance to read any properties.

     

    In stacktrace you see the 2 blocking and waiting threads  (XmlConfigLocal is the local interface of the Singleton EJB):

    "MSC service thread 1-2" prio=10 tid=0x80d06000 nid=0x44ca in Object.wait() [0x8076c000]

       java.lang.Thread.State: WAITING (on object monitor)

        at java.lang.Object.wait(Native Method)

        at java.lang.Object.wait(Object.java:503)

        at org.jboss.as.ee.component.BasicComponent.waitForComponentStart(BasicComponent.java:109)

        - locked <0x83432890> (a org.jboss.as.ejb3.component.singleton.SingletonComponent)

        at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:127)

        at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85)

        at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:116)

        - locked <0x83467f00> (a java.lang.Object)

        at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228)

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304)

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)

        at serverview.common.javaee.xml_config.XmlConfigLocal$$$view9.getJAXBElement(Unknown Source)

        at serverview.common.javaee.lib.utilities.ConfigCore.update(ConfigCore.java:112)

        at serverview.common.javaee.lib.utilities.ConfigCore.<init>(ConfigCore.java:75)

        at serverview.common.javaee.security.common.lib.config.Config.<init>(Config.java:38)

        at serverview.common.javaee.security.common.lib.config.SecUtils.getConfig(SecUtils.java:28)

        at serverview.common.javaee.security.servlet_filter.TGTInsertionFilter.init(TGTInsertionFilter.java:218)

        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:447)

        at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3269)

        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3865)

        - locked <0x8e202e18> (a org.apache.catalina.core.StandardContext)

        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90)

        - locked <0x8e1c7790> (a org.jboss.as.web.deployment.WebDeploymentService)

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

        at java.lang.Thread.run(Unknown Source)

     

    "MSC service thread 1-1" prio=10 tid=0x80568c00 nid=0x44c9 waiting for monitor entry [0x80980000]

       java.lang.Thread.State: BLOCKED (on object monitor)

        at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:115)

        - waiting to lock <0x83467f00> (a java.lang.Object)

        at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:228)

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304)

        at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

        at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

        at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173)

        at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

        at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

        at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)

        at serverview.common.javaee.xml_config.XmlConfigLocal$$$view9.getJAXBElement(Unknown Source)

        at serverview.common.javaee.lib.utilities.ConfigCore.update(ConfigCore.java:112)

        at serverview.common.javaee.lib.utilities.ConfigCore.<init>(ConfigCore.java:75)

        at serverview.common.javaee.security.common.lib.config.Config.<init>(Config.java:38)

        at serverview.common.javaee.security.common.lib.config.SecUtils.getConfig(SecUtils.java:28)

        at serverview.common.javaee.security.servlet_filter.TGTInsertionFilter.init(TGTInsertionFilter.java:218)

        at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:447)

        at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3269)

        at org.apache.catalina.core.StandardContext.start(StandardContext.java:3865)

        - locked <0x8e58aa40> (a org.apache.catalina.core.StandardContext)

        at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:90)

        - locked <0x8e58cc78> (a org.jboss.as.web.deployment.WebDeploymentService)

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811)

        at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

        at java.lang.Thread.run(Unknown Source)

     

    We are wondering why the singleton isn't started before.

     

    With our workaround (using jboss-cli.sh for deploying in a defined serial order) we have no deployment problems. The problem occurs again, when stopping and starting JBoss. Therefore we are deactivating(activating our applications at shutdown/start of JBoss.

     

    Baerbel

  • 10. Re: Deployment on linux leads to transaction problems
    Baerbel Lindner Newbie

    Hi,

     

    some additional information: The jndi context of our Singleton bean is published:

    19:41:20,176 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named XmlConfigBean in deployment unit deployment "xml-config.jar" are as follows:

     

        java:global/xml-config/XmlConfigBean!serverview.common.javaee.xml_config.XmlConfigLocal

        java:app/xml-config/XmlConfigBean!serverview.common.javaee.xml_config.XmlConfigLocal

        java:module/XmlConfigBean!serverview.common.javaee.xml_config.XmlConfigLocal

        java:global/xml-config/XmlConfigBean

        java:app/xml-config/XmlConfigBean

        java:module/XmlConfigBean

     

    the interceptors are registered:

    19:41:25,235 TRACE [org.jboss.as.jpa] (MSC service thread 1-1) registering session bean interceptors for component 'XmlConfigBean' in 'xml-config.jar'

     

    but the Bean class is not loaded until the deployment deadlock occurs.

  • 11. Re: Deployment on linux leads to transaction problems
    Frank Haverland Newbie

    Looks like in our case, we have a solution. We have a few of Singleton's for Timer initialization. The singleton has all @Startup Annotations and call a Sessionbean, that initialize the timer. In that bean the call another Singleton with @Startup, that not started up before. And here waiting all Singelton and Sessionbeans how call the ConfigurationSingleton.

     

    Or Short

     

    TimerSingleton => TimerSessionBean => ConfigurationSingleton (not intitialized before)

     

    We removed the @PostConstruct - Method and @Startup from ConfigurationSingleton. The Locks disappiert.

  • 12. Re: Deployment on linux leads to transaction problems
    Baerbel Lindner Newbie

    Our solution is:

    We moved the Singleton EJB calls from filter's init() method to the doFilter() method. This workaround avoids the deployment deadlocks.

    It seems to be that it JBoss 7 has problems with filters that are calling EJBs in their init method. The init method are sometimes called prior to the deployment ofthe  EJBs.

     

    I don't know why these deployment deadlocks only appear on our linux systems and not on the windows systems.