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

        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

          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
            aravindsk

            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

              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
                aravindsk

                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.

                • 35. Re: SLSB pool size is always one in jboss 6.0 CR1 using ejb 3.1
                  aravindsk

                  sorry about that confusion on the logs.

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

                    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

                      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
                        aravindsk

                        Thank you. will adjust the timeout accordingly.

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

                          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
                            garrydias

                            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
                              wolfc

                              Please open up your own thread, no thread hijacking.

                              1 2 3 Previous Next