1 2 3 Previous Next 41 Replies Latest reply on Sep 7, 2011 1:23 PM by Carlo de Wolf Go to original post
      • 30. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
        aravind kopparthi Newbie

        i changed the implementation little bit such that i have completely removed the SingtonScheduleBean and moved the timer to SLSBean. from functionlaity wise it is doing exactly what i was expected in terms of firing timeout by container (timerservice) and calling aviable SLSB instances from the pool as i limited to 7. in the ejb-interseptors-aop.xml using StrictMaxPool=7

        but server throws below exception( this make sense because i ristricted slsbs to be 7) and if the TimerService expires it has to wait for the SLSBs from completing their current process to get the 8th one.

         

        how to stop these ERRORS to be thrown in logs.

         

         

         

        16:54:46,343 ERROR [org.jboss.ejb3.timerservice.mk2.task.TimerTask] Error during retyring timeout for timer: [id=960cd66d-3726-481b-a617-5e298ce86b73 timedObjectId=jboss.j2ee:jar=javaee6-app.war,name=SLSBProcessBean,service=EJB3 auto-timer?:true persistent?:false timerService=org.jboss.ejb3.timerservice.mk2.TimerServiceImpl@2cfbd8 initialExpiration=Wed Nov 24 00:00:00 EST 2010 intervalDuration(in milli sec)=0 nextExpiration=Wed Nov 24 16:53:22 EST 2010 timerState=IN_TIMEOUT: javax.ejb.EJBException: Failed to acquire the pool semaphore, strictTimeout=10000

        at org.jboss.ejb3.pool.StrictMaxPool.acquire(StrictMaxPool.java:86) [:1.6.3]

        at org.jboss.ejb3.pool.StrictMaxPool.get(StrictMaxPool.java:145) [:1.6.3]

        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:58) [:1.6.3]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.ejb3.core.context.SessionInvocationContextAdapter.proceed(SessionInvocationContextAdapter.java:91) [:1.6.3]

        at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:247) [:0.0.1]

        at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:349) [:0.0.1]

        at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209) [:0.0.1]

        at org.jboss.ejb3.tx2.aop.CMTTxInterceptorWrapper.invoke(CMTTxInterceptorWrapper.java:52) [:0.0.1]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) [:1.0.0.GA]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) [:1.6.3]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) [:1.6.3]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.6.3]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) [:1.6.3]

        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]

        at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:692) [:1.6.3]

        at org.jboss.ejb3.timerservice.mk2.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:80) [:1.0.0-alpha-10]

        at org.jboss.ejb3.timerservice.mk2.task.TimerTask.run(TimerTask.java:127) [:1.0.0-alpha-10]

        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_13]

        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_13]

        at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_13]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) [:1.6.0_13]

        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207) [:1.6.0_13]

        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_13]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_13]

        at java.lang.Thread.run(Thread.java:619) [:1.6.0_13]

         

         

        16:54:46,343 ERROR [org.jboss.ejb3.timerservice.mk2.task.TimerTask] Error during retyring timeout for timer: [id=960cd66d-3726-481b-a617-5e298ce86b73 timedObjectId=jboss.j2ee:jar=javaee6-app.war,name=SLSBProcessBean,service=EJB3 auto-timer?:true persistent?:false timerService=org.jboss.ejb3.timerservice.mk2.TimerServiceImpl@2cfbd8 initialExpiration=Wed Nov 24 00:00:00 EST 2010 intervalDuration(in milli sec)=0 nextExpiration=Wed Nov 24 16:53:22 EST 2010 timerState=IN_TIMEOUT: javax.ejb.EJBException: Failed to acquire the pool semaphore, strictTimeout=10000
        at org.jboss.ejb3.pool.StrictMaxPool.acquire(StrictMaxPool.java:86) [:1.6.3]
        at org.jboss.ejb3.pool.StrictMaxPool.get(StrictMaxPool.java:145) [:1.6.3]
        at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:58) [:1.6.3]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.ejb3.core.context.SessionInvocationContextAdapter.proceed(SessionInvocationContextAdapter.java:91) [:1.6.3]
        at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:247) [:0.0.1]
        at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.required(CMTTxInterceptor.java:349) [:0.0.1]
        at org.jboss.ejb3.tx2.impl.CMTTxInterceptor.invoke(CMTTxInterceptor.java:209) [:0.0.1]
        at org.jboss.ejb3.tx2.aop.CMTTxInterceptorWrapper.invoke(CMTTxInterceptorWrapper.java:52) [:0.0.1]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76) [:1.0.0.GA]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41) [:1.6.3]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67) [:1.6.3]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.ejb3.core.context.CurrentInvocationContextInterceptor.invoke(CurrentInvocationContextInterceptor.java:47) [:1.6.3]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67) [:1.0.1]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.ejb3.interceptor.EJB3TCCLInterceptor.invoke(EJB3TCCLInterceptor.java:86) [:1.6.3]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.ejb3.stateless.StatelessContainer.callTimeout(StatelessContainer.java:692) [:1.6.3]
        at org.jboss.ejb3.timerservice.mk2.task.CalendarTimerTask.callTimeout(CalendarTimerTask.java:80) [:1.0.0-alpha-10]
        at org.jboss.ejb3.timerservice.mk2.task.TimerTask.run(TimerTask.java:127) [:1.0.0-alpha-10]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_13]
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_13]
        at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_13]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98) [:1.6.0_13]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207) [:1.6.0_13]
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_13]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_13]
        at java.lang.Thread.run(Thread.java:619) [:1.6.0_13]
        • 31. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
          Jaikiran Pai Master

          You are configuring to be strict and of a specific max size. Effectively when that size is reached, it's going to throw an error for the next instance. So if you want to get rid of that error then obviously increase the pool size.

          • 32. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
            aravind kopparthi Newbie

            http://community.jboss.org/message/572522#572522 if you see this link and scroll down to see the logs what were generated when i used Lock(Type.READ)

             

            i am pasting it here again

             

            12:02:34,156 INFO  [STDOUT] TIMEOUT METHOD CALLED

             

            12:03:02,343 INFO  [STDOUT] process complete in slsb

             

            12:03:02,390 INFO  [STDOUT] TIMEOUT METHOD CALLED

             

            12:03:15,343 INFO  [STDOUT] process complete in slsb

             

            12:03:15,343 INFO  [STDOUT] TIMEOUT METHOD CALLED

             

            12:03:29,093 INFO  [STDOUT] process complete in slsb

             

            12:03:29,093 INFO  [STDOUT] process complete in slsb

             

            12:03:38,421 INFO  [STDOUT] process complete in slsb

             

            12:03:38,421 INFO  [STDOUT] TIMEOUT METHOD CALLED

            • 33. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
              Jaikiran Pai Master

              aravind kopparthi wrote:

               

              http://community.jboss.org/message/572522#572522 if you see this link and scroll down to see the logs what were generated when i used Lock(Type.READ)

               

              Okay, so either I did not pay attention to that post or you went and edited the original code and the logs in that post, because from what I remember it did not have the LockType.READ when I first saw it. If you have been editing your posts then please do not do that, it messes up the discussion.

              • 34. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                aravind kopparthi Newbie

                since i have made some changes to the design( not using Singleton with Scheduler and also not using @Asynchronous in SLSBs)

                I am fine with the solution that i was offered here using StrictMaxPool instead of default ThreadLocalPool in ejb3-interseptors-aop.xml. thanks so much for your support.

                • 36. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                  aravind kopparthi Newbie

                  So if you want to get rid of that error then obviously increase the pool size.

                  I would like container to wait until next slsb is available from the pool. by increasing the pool size with out knowing how many are required wouldn't it degrade server performance?

                  • 37. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                    Jaikiran Pai Master

                    aravind kopparthi wrote:

                     

                     

                    I would like container to wait until next slsb is available from the pool.

                    The container can't wait indefinitely for the next instance. Atleast we don't have any out of the box pool implementation that does that. You can however set an appropriate timeout on how long you want the container to wait for the next instance http://docs.jboss.org/ejb3/docs/reference/1.0.7/html/SessionBean_and_MDB_configuration.html

                    • 38. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                      aravind kopparthi Newbie

                      Thank you. will adjust the timeout accordingly.

                      • 39. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                        Garry Dias Newbie

                        Hello .. I have a similar issue but in jboss 5.1 using ejb 3.0

                         

                        My clustered app process thousands requests but I have problems in only one node.

                         

                        My bean is annotated with StrictMaxPool=100 without strictTimeout. Sometimes the max pool size is reached and the incoming requests (new bean instances creation in the pool) are blocked with Failed to acquire the pool semaphore, strictTimeout=-1. Until now it´s an application regular behavior.

                         

                        When beans creation requests  decreases my ejb blocks new instances creation =/ and Failed to acquire the pool semaphore, strictTimeout=-1 occurs all the time. It´s like the pool is still full but in JMX-CONSOLE (domain j2ee, service=EJB3) and accessing MyWorkerBean link, the AvailableCount attribute is always 0  (until in other clustered node this attribute increases and decreases normally) and worse: no bean is instantiated anymore. My pool is empty but the container can´t instatiate MyWorkerBeans anymore. Why???

                         

                        I´ll appreciate any help

                         

                        thanks

                         

                        • 40. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                          Garry Dias Newbie

                          adding.... It is solved when the server is restarted but it is not a good approach. I want to solve this problem definitively

                           

                          thanks

                          • 41. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                            Carlo de Wolf Master

                            Please open up your own thread, no thread hijacking.

                            1 2 3 Previous Next