You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by José Luis Cetina <ma...@gmail.com> on 2013/03/06 16:46:58 UTC
ConcurrentAccessTimeoutException
Hi im gettin *ConcurrentAccessTimeoutException: No instances available in
Stateless Session Bean pool. Waited 30 SECONDS....*
Here is the complete log: http://pastebin.ca/2328770
Any advice, what could be? Do i have to configure something in tomee.xml??
Part of the log:
*Mar 05, 2013 9:38:20 PM org.apache.openejb.cdi.CdiAppContextsService
lazyStartSessionContext
WARNING: Could NOT lazily initialize session context because of null
RequestContext
javax.ejb.ConcurrentAccessTimeoutException: No instances available in
Stateless Session Bean pool. Waited 30 SECONDS
at
org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
at
org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
at
org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
at
com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
at
org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
at
org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
at
org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
at
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
at
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
at
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
at
org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
at
org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
at javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
at
javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
at
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
*
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Was talking to someone today, and when I told him that I used @Singleton in
my app, he reminded me that @Singleton is not good for scalability
(clustering/etc...).
On Thu, Mar 7, 2013 at 7:10 PM, David Blevins <da...@gmail.com>wrote:
> I'd also recommend @Singleton in conjunction with @Lock(READ).
>
> The @Stateless bean type is good when you explicitly need to limit the
> number of instances/concurrent calls. If this sort of limiting is not a
> critical part of the design, then likely @Stateless was used because this
> is the bean type people tend to use by default.
>
> Really, @Singleton with @Lock(READ) should be used by default and other
> bean types used only when there is a specific design goal you need to
> achieve.
>
>
> -David
>
> On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > In very very heavy load and for a simple app it can be as much as your
> http
> > request thread pool size (200 by default)
> >
> > Note: using @Singleton can help too if you can
> > Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a écrit
> :
> >
> >> Really im not sure how many users the webapp could handle, because is a
> >> public webapp, i will increase the MaxSize to 50 or 100, but for any
> >> "unexpected
> >> overload" i will let StrictPooling to false.
> >>
> >> Do you consider its to much to increase to 50/100 to maxsize??
> >>
> >>
> >>
> >> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
> >>
> >>> José,
> >>>
> >>> The MinSize is not the problem IMO.
> >>> The MaxSize is definitely the issue. Do you have more than 10 (default
> >>> value) simultaneous users?
> >>>
> >>> The StrictPooling is great to be able to always answer in case of small
> >>> over load.
> >>> But, you have to know that after being used, instances will be removed
> >> and
> >>> garbage collected.
> >>>
> >>> Also, creating instances can be consuming depending on the bean.
> >>>
> >>> I would recommend not only to set it to true, but before, trying to
> >> define
> >>> as much as possible the correct value for MaxSize depending on your
> SLAs.
> >>>
> >>> Hope it helps
> >>> JLouis
> >>>
> >>>
> >>>
> >>>
> >>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
> >>>
> >>>> Im using 1.6.0-SNAPSHOT.
> >>>>
> >>>> I will change
> >>>>
> >>>> StrictPooling = true ==> false
> >>>> MinSize = 0 ==> 2
> >>>>
> >>>> In stateless section and let you know.
> >>>>
> >>>>
> >>>>
> >>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> >>>>
> >>>>> José,
> >>>>>
> >>>>> I'm sure the others will ask, are you seeing this with tomee 1.5.2 or
> >>>> 1.6.0
> >>>>> snapshot? or only seeing on your production server running tomee
> >> 1.5.1
> >>>> or
> >>>>> 1.5.2 / 1.6.0 snapshot?
> >>>>>
> >>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> >>>>>
> >>>>> Also, i searched google for the following:
> >>>>>
> >>>>> No instances available in Stateless Session Bean pool
> >>>>>
> >>>>> and found the following (which is definitely related to Jean-Louis
> >>>>> response):
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> >>>>>
> >>>>> [2]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> >>>>>
> >>>>> [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> >>>>>
> >>>>>
> >>>>> Howard
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> >>> maxtorzito@gmail.com
> >>>>>> wrote:
> >>>>>
> >>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
> >>> available
> >>>> in
> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
> >>>>>>
> >>>>>> Here is the complete log: http://pastebin.ca/2328770
> >>>>>>
> >>>>>> Any advice, what could be? Do i have to configure something in
> >>>>> tomee.xml??
> >>>>>>
> >>>>>> Part of the log:
> >>>>>>
> >>>>>>
> >>>>>> *Mar 05, 2013 9:38:20 PM
> >> org.apache.openejb.cdi.CdiAppContextsService
> >>>>>> lazyStartSessionContext
> >>>>>> WARNING: Could NOT lazily initialize session context because of
> >> null
> >>>>>> RequestContext
> >>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances available
> >> in
> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> >>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> >>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> >>>>>> at
> >> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> >>>>>> at
> >> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> >>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> >>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> >>>>>> at
> >>>>>
> >>>
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> >>>>>> at
> >>>>>
> >>>
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> >>>>>> at
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> >>>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> >>>>>> at
> >>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> >>>>>> at
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> >>>>>> at
> >> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>> *
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -------------------------------------------------------------------
> >>>> *SCJA. José Luis Cetina*
> >>>> -------------------------------------------------------------------
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jean-Louis
> >>>
> >>
> >>
> >>
> >> --
> >> -------------------------------------------------------------------
> >> *SCJA. José Luis Cetina*
> >> -------------------------------------------------------------------
> >>
>
>
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
well @Singleton + @Lock(READ) means your bean should be stateless (that's
the cause for WS in general) so that's a good choice
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/8 James Green <ja...@gmail.com>
> This leads nicely to a question I was about to pose on StackOverflow (where
> I would expect it to have been answered already): For stateless web
> services implemented using JAX-WS and JAX-RS should we be using @Stateless
> or @Singleton?
>
> I ask because without the production level experience telling me otherwise,
> I would envisage @Singleton causing a queuing effect for incoming requests
> to the same endpoint.
>
> An example of the "right way" would be helpful to clarify matters.
>
> Thanks,
>
> James
>
>
>
> On 8 March 2013 00:10, David Blevins <da...@gmail.com> wrote:
>
> > I'd also recommend @Singleton in conjunction with @Lock(READ).
> >
> > The @Stateless bean type is good when you explicitly need to limit the
> > number of instances/concurrent calls. If this sort of limiting is not a
> > critical part of the design, then likely @Stateless was used because this
> > is the bean type people tend to use by default.
> >
> > Really, @Singleton with @Lock(READ) should be used by default and other
> > bean types used only when there is a specific design goal you need to
> > achieve.
> >
> >
> > -David
> >
> > On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <rm...@gmail.com>
> > wrote:
> >
> > > In very very heavy load and for a simple app it can be as much as your
> > http
> > > request thread pool size (200 by default)
> > >
> > > Note: using @Singleton can help too if you can
> > > Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a
> écrit
> > :
> > >
> > >> Really im not sure how many users the webapp could handle, because is
> a
> > >> public webapp, i will increase the MaxSize to 50 or 100, but for any
> > >> "unexpected
> > >> overload" i will let StrictPooling to false.
> > >>
> > >> Do you consider its to much to increase to 50/100 to maxsize??
> > >>
> > >>
> > >>
> > >> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
> > >>
> > >>> José,
> > >>>
> > >>> The MinSize is not the problem IMO.
> > >>> The MaxSize is definitely the issue. Do you have more than 10
> (default
> > >>> value) simultaneous users?
> > >>>
> > >>> The StrictPooling is great to be able to always answer in case of
> small
> > >>> over load.
> > >>> But, you have to know that after being used, instances will be
> removed
> > >> and
> > >>> garbage collected.
> > >>>
> > >>> Also, creating instances can be consuming depending on the bean.
> > >>>
> > >>> I would recommend not only to set it to true, but before, trying to
> > >> define
> > >>> as much as possible the correct value for MaxSize depending on your
> > SLAs.
> > >>>
> > >>> Hope it helps
> > >>> JLouis
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
> > >>>
> > >>>> Im using 1.6.0-SNAPSHOT.
> > >>>>
> > >>>> I will change
> > >>>>
> > >>>> StrictPooling = true ==> false
> > >>>> MinSize = 0 ==> 2
> > >>>>
> > >>>> In stateless section and let you know.
> > >>>>
> > >>>>
> > >>>>
> > >>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> > >>>>
> > >>>>> José,
> > >>>>>
> > >>>>> I'm sure the others will ask, are you seeing this with tomee 1.5.2
> or
> > >>>> 1.6.0
> > >>>>> snapshot? or only seeing on your production server running tomee
> > >> 1.5.1
> > >>>> or
> > >>>>> 1.5.2 / 1.6.0 snapshot?
> > >>>>>
> > >>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> > >>>>>
> > >>>>> Also, i searched google for the following:
> > >>>>>
> > >>>>> No instances available in Stateless Session Bean pool
> > >>>>>
> > >>>>> and found the following (which is definitely related to Jean-Louis
> > >>>>> response):
> > >>>>>
> > >>>>> [1]
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> > >>>>>
> > >>>>> [2]
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> > >>>>>
> > >>>>> [3]
> http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> > >>>>>
> > >>>>>
> > >>>>> Howard
> > >>>>>
> > >>>>>
> > >>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> > >>> maxtorzito@gmail.com
> > >>>>>> wrote:
> > >>>>>
> > >>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
> > >>> available
> > >>>> in
> > >>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
> > >>>>>>
> > >>>>>> Here is the complete log: http://pastebin.ca/2328770
> > >>>>>>
> > >>>>>> Any advice, what could be? Do i have to configure something in
> > >>>>> tomee.xml??
> > >>>>>>
> > >>>>>> Part of the log:
> > >>>>>>
> > >>>>>>
> > >>>>>> *Mar 05, 2013 9:38:20 PM
> > >> org.apache.openejb.cdi.CdiAppContextsService
> > >>>>>> lazyStartSessionContext
> > >>>>>> WARNING: Could NOT lazily initialize session context because of
> > >> null
> > >>>>>> RequestContext
> > >>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances available
> > >> in
> > >>>>>> Stateless Session Bean pool. Waited 30 SECONDS
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> > >>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> > >>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> > >>>>>> at
> > >> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> > >>>>>> at
> > >> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> > >>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> > >>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> > >>>>>> at
> > >>>>>
> > >>>
> > org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> > >>>>>> at
> > >>>>>
> > >>>
> > javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> > >>>>>> at
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> > >>>>>> at
> > >>>>>>
> > >>>>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> > >>>>>> at
> > >>>>>>
> > >>>>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > >>>>>> at
> > >>>>>>
> > >>>>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > >>>>>> at
> > >>>>>>
> > >>>>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> > >>>>>> at
> > >>>>>>
> > >>>>
> > >>
> > org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> > >>>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> > >>>>>> at
> > >>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> > >>>>>> at
> > >>>>>>
> > >>>>
> > >>
> > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> > >>>>>> at
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> > >>>>>> at
> > >> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > >>>>>> at
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > >>>>>> at java.lang.Thread.run(Thread.java:722)
> > >>>>>> *
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> -------------------------------------------------------------------
> > >>>> *SCJA. José Luis Cetina*
> > >>>> -------------------------------------------------------------------
> > >>>>
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Jean-Louis
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> -------------------------------------------------------------------
> > >> *SCJA. José Luis Cetina*
> > >> -------------------------------------------------------------------
> > >>
> >
> >
>
Re: ConcurrentAccessTimeoutException
Posted by James Green <ja...@gmail.com>.
This leads nicely to a question I was about to pose on StackOverflow (where
I would expect it to have been answered already): For stateless web
services implemented using JAX-WS and JAX-RS should we be using @Stateless
or @Singleton?
I ask because without the production level experience telling me otherwise,
I would envisage @Singleton causing a queuing effect for incoming requests
to the same endpoint.
An example of the "right way" would be helpful to clarify matters.
Thanks,
James
On 8 March 2013 00:10, David Blevins <da...@gmail.com> wrote:
> I'd also recommend @Singleton in conjunction with @Lock(READ).
>
> The @Stateless bean type is good when you explicitly need to limit the
> number of instances/concurrent calls. If this sort of limiting is not a
> critical part of the design, then likely @Stateless was used because this
> is the bean type people tend to use by default.
>
> Really, @Singleton with @Lock(READ) should be used by default and other
> bean types used only when there is a specific design goal you need to
> achieve.
>
>
> -David
>
> On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > In very very heavy load and for a simple app it can be as much as your
> http
> > request thread pool size (200 by default)
> >
> > Note: using @Singleton can help too if you can
> > Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a écrit
> :
> >
> >> Really im not sure how many users the webapp could handle, because is a
> >> public webapp, i will increase the MaxSize to 50 or 100, but for any
> >> "unexpected
> >> overload" i will let StrictPooling to false.
> >>
> >> Do you consider its to much to increase to 50/100 to maxsize??
> >>
> >>
> >>
> >> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
> >>
> >>> José,
> >>>
> >>> The MinSize is not the problem IMO.
> >>> The MaxSize is definitely the issue. Do you have more than 10 (default
> >>> value) simultaneous users?
> >>>
> >>> The StrictPooling is great to be able to always answer in case of small
> >>> over load.
> >>> But, you have to know that after being used, instances will be removed
> >> and
> >>> garbage collected.
> >>>
> >>> Also, creating instances can be consuming depending on the bean.
> >>>
> >>> I would recommend not only to set it to true, but before, trying to
> >> define
> >>> as much as possible the correct value for MaxSize depending on your
> SLAs.
> >>>
> >>> Hope it helps
> >>> JLouis
> >>>
> >>>
> >>>
> >>>
> >>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
> >>>
> >>>> Im using 1.6.0-SNAPSHOT.
> >>>>
> >>>> I will change
> >>>>
> >>>> StrictPooling = true ==> false
> >>>> MinSize = 0 ==> 2
> >>>>
> >>>> In stateless section and let you know.
> >>>>
> >>>>
> >>>>
> >>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> >>>>
> >>>>> José,
> >>>>>
> >>>>> I'm sure the others will ask, are you seeing this with tomee 1.5.2 or
> >>>> 1.6.0
> >>>>> snapshot? or only seeing on your production server running tomee
> >> 1.5.1
> >>>> or
> >>>>> 1.5.2 / 1.6.0 snapshot?
> >>>>>
> >>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> >>>>>
> >>>>> Also, i searched google for the following:
> >>>>>
> >>>>> No instances available in Stateless Session Bean pool
> >>>>>
> >>>>> and found the following (which is definitely related to Jean-Louis
> >>>>> response):
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> >>>>>
> >>>>> [2]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> >>>>>
> >>>>> [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> >>>>>
> >>>>>
> >>>>> Howard
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> >>> maxtorzito@gmail.com
> >>>>>> wrote:
> >>>>>
> >>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
> >>> available
> >>>> in
> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
> >>>>>>
> >>>>>> Here is the complete log: http://pastebin.ca/2328770
> >>>>>>
> >>>>>> Any advice, what could be? Do i have to configure something in
> >>>>> tomee.xml??
> >>>>>>
> >>>>>> Part of the log:
> >>>>>>
> >>>>>>
> >>>>>> *Mar 05, 2013 9:38:20 PM
> >> org.apache.openejb.cdi.CdiAppContextsService
> >>>>>> lazyStartSessionContext
> >>>>>> WARNING: Could NOT lazily initialize session context because of
> >> null
> >>>>>> RequestContext
> >>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances available
> >> in
> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> >>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> >>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> >>>>>> at
> >> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> >>>>>> at
> >> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> >>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> >>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> >>>>>> at
> >>>>>
> >>>
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> >>>>>> at
> >>>>>
> >>>
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> >>>>>> at
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> >>>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> >>>>>> at
> >>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> >>>>>> at
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> >>>>>> at
> >> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>> *
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -------------------------------------------------------------------
> >>>> *SCJA. José Luis Cetina*
> >>>> -------------------------------------------------------------------
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jean-Louis
> >>>
> >>
> >>
> >>
> >> --
> >> -------------------------------------------------------------------
> >> *SCJA. José Luis Cetina*
> >> -------------------------------------------------------------------
> >>
>
>
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Well, I have learned (and thanks for the reminder) not to use Singleton for
DB operations, because I tried @Singleton with @Schedule to automate some
batch database inserts, and that caused deadlock throughout the app and I
definitely got calls from endusers, so I had to refactor the code and
replace that with a hyperlink/button for enduser to click to initiate the
database insert (after downloading data from public website).
anyway, I am hoping to trying to automate t his one again, but now via use
of ActiveMQ/MessageDrivenBeans (MDBs). I'll let @Singleton @Schedule
trigger the download, but clearly/definitely, the database insert will
occur via ActiveMQ/MDB. I'm loving ActiveMQ and MDB these days and using
where possible.
And yes, the MDB will access my @Stateless EJBs which already access
database via single EM.
On Wed, Mar 13, 2013 at 11:02 AM, zeeman <ha...@fastmail.us> wrote:
> Yes, Spring uses singleton by default for beans. But for Repo and DB
> classes
> Spring has its own way of handling that. As I mentioned using a Singleton
> in
> a bean that deals with the DB is a big scalability issue. All DB calls will
> be going through a single EM/DB connection. With stateless that's not the
> case.
>
> Another mistake I see people make is where they use singletone with @Async
> and forget about thread safety of EM and other resources. This issue does
> not apply to stateless bean as each invocation has its own instance.
>
> I would use Singletons where no DB or external services are called
> (concurrent requests). Otherwise, I would use stateless.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661508.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
well the definition of cdi beans is pretty explicit: each beans are a
singleton in a particular scope. So basically no pool with defaults scopes
(you can still imagine your own weird scope ;).
that said, this thread is interesting but the title doesn't match anymore
the content, if you want to continue maybe we should open another thread,
no?
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/14 James Green <ja...@gmail.com>
> By comparison, are beans held in a CDI scope managed in a pool with min/max
> boundaries?
>
> I've been trying to avoid using EJBs - probably due to seeing them being
> registered at boot and my thinking that it's probably a waste of RAM when
> they are idle. Right now I have @Stateless on my JAX-RS and JAX-WS classes
> but use CDI on the backend.
>
> A repercussion of this was that @Dependant beans were being reused by the
> JAX-RS classes across invocations which I hadn't appreciated would be the
> case. I tried switching to @RequestScoped but something blew up. Elsewhere
> an @RequestScoped bean with a constructor that had @Inject parameter also
> blew up. I had to remove these quickly to get a demo up and running again
> but it revealed a level of interaction complexity I had not anticipated
> from skim reading what I found in examples on the web.
>
>
> On 14 March 2013 03:59, Anthony Fryer <ap...@hotmail.com> wrote:
>
> > +1 for Stateless Session Beans. I've never had an issue with them and
> find
> > them a good way to control resource utilization. The only things to keep
> > in
> > mind is what your min and max pool sizes are for the beans. If you make
> > that match up with the number of threads, then you shouldn't have any
> > threads blocking waiting for a free bean. I usually set min and max to
> the
> > same value since i don't see much value in having a pool shrink or grow.
> > Also good to keep in mind if you inject other EJBs into an EJB, then its
> > the
> > EJB with the smallest pool size that could cause a thread to block.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661516.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
>
Re: ConcurrentAccessTimeoutException
Posted by James Green <ja...@gmail.com>.
By comparison, are beans held in a CDI scope managed in a pool with min/max
boundaries?
I've been trying to avoid using EJBs - probably due to seeing them being
registered at boot and my thinking that it's probably a waste of RAM when
they are idle. Right now I have @Stateless on my JAX-RS and JAX-WS classes
but use CDI on the backend.
A repercussion of this was that @Dependant beans were being reused by the
JAX-RS classes across invocations which I hadn't appreciated would be the
case. I tried switching to @RequestScoped but something blew up. Elsewhere
an @RequestScoped bean with a constructor that had @Inject parameter also
blew up. I had to remove these quickly to get a demo up and running again
but it revealed a level of interaction complexity I had not anticipated
from skim reading what I found in examples on the web.
On 14 March 2013 03:59, Anthony Fryer <ap...@hotmail.com> wrote:
> +1 for Stateless Session Beans. I've never had an issue with them and find
> them a good way to control resource utilization. The only things to keep
> in
> mind is what your min and max pool sizes are for the beans. If you make
> that match up with the number of threads, then you shouldn't have any
> threads blocking waiting for a free bean. I usually set min and max to the
> same value since i don't see much value in having a pool shrink or grow.
> Also good to keep in mind if you inject other EJBs into an EJB, then its
> the
> EJB with the smallest pool size that could cause a thread to block.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661516.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: ConcurrentAccessTimeoutException
Posted by Anthony Fryer <ap...@hotmail.com>.
+1 for Stateless Session Beans. I've never had an issue with them and find
them a good way to control resource utilization. The only things to keep in
mind is what your min and max pool sizes are for the beans. If you make
that match up with the number of threads, then you shouldn't have any
threads blocking waiting for a free bean. I usually set min and max to the
same value since i don't see much value in having a pool shrink or grow.
Also good to keep in mind if you inject other EJBs into an EJB, then its the
EJB with the smallest pool size that could cause a thread to block.
--
View this message in context: http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661516.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
What is cool with JavaEE is it guarantees a "sure" default way allowing to
go further when correcty understood and desired ;)
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/13 zeeman <ha...@fastmail.us>
> Yes, done manually and most people don't do it right. Anyway, for Tomee and
> CDI I would follow what I said. Other routes are possible and error prone.
> At least from my experience.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661512.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: ConcurrentAccessTimeoutException
Posted by zeeman <ha...@fastmail.us>.
Yes, done manually and most people don't do it right. Anyway, for Tomee and
CDI I would follow what I said. Other routes are possible and error prone.
At least from my experience.
--
View this message in context: http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661512.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
even in spring the em is thread safe (in tx mode) when well
configured...but need to be done manually
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/13 zeeman <ha...@fastmail.us>
> Yes, Spring uses singleton by default for beans. But for Repo and DB
> classes
> Spring has its own way of handling that. As I mentioned using a Singleton
> in
> a bean that deals with the DB is a big scalability issue. All DB calls will
> be going through a single EM/DB connection. With stateless that's not the
> case.
>
> Another mistake I see people make is where they use singletone with @Async
> and forget about thread safety of EM and other resources. This issue does
> not apply to stateless bean as each invocation has its own instance.
>
> I would use Singletons where no DB or external services are called
> (concurrent requests). Otherwise, I would use stateless.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661508.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: ConcurrentAccessTimeoutException
Posted by zeeman <ha...@fastmail.us>.
Yes, Spring uses singleton by default for beans. But for Repo and DB classes
Spring has its own way of handling that. As I mentioned using a Singleton in
a bean that deals with the DB is a big scalability issue. All DB calls will
be going through a single EM/DB connection. With stateless that's not the
case.
Another mistake I see people make is where they use singletone with @Async
and forget about thread safety of EM and other resources. This issue does
not apply to stateless bean as each invocation has its own instance.
I would use Singletons where no DB or external services are called
(concurrent requests). Otherwise, I would use stateless.
--
View this message in context: http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661508.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: ConcurrentAccessTimeoutException
Posted by James Green <ja...@gmail.com>.
Ironic how other projects have driven out Singletons from their code - was
it PHP Symphony or something like that? Anyway, all things in their place.
On 13 March 2013 14:32, Howard W. Smith, Jr. <sm...@gmail.com> wrote:
> Interesting conversation/facts/etc... here!
>
> singleton is basically the model that 'spring' propagated for years? wow
> (shaking my head)... I purposely have avoided being or becoming a 'spring'
> user and said to myself, Java EE 6 (reference implementation) clearly is
> sufficient to meet any/all my Java EE needs. :)
>
> anyway, i am using @Singleton more and more in my app...thanks to advice
> given by David Blevins months ago. :)
>
>
> On Wed, Mar 13, 2013 at 4:46 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > was no more clear for me ;)
> >
> > singleton is basically the model spring propagated for years and which is
> > now known as very efficient
> >
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/3/13 Jean-Louis MONTEIRO <je...@gmail.com>
> >
> > > I agree Romain, but it only works in that specific situation:
> > > - EM type=TRANSACTION (not Extended)
> > > - Java EE environment (not Java SE)
> > >
> > > And I also agree using a Singleton bean makes both true as it's not
> > allowed
> > > as per the spec to obtain an Extended PC in a Singleton.
> > >
> > > My purpose was just to try to get things clearer.
> > >
> > > Jean-Louis
> > >
> > >
> > > 2013/3/13 Romain Manni-Bucau <rm...@gmail.com>
> > >
> > > > Em is clearly thread safe in a javaee envrt in transaction mode...at
> > > least
> > > > because of the transaction constraint you can get the same instance
> in
> > > > different threads
> > > > Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <je...@gmail.com> a
> > > écrit
> > > > :
> > > >
> > > > > As a pure user feedback, we've been using OpenEJB/TomEE stateless
> > beans
> > > > on
> > > > > huge applications and it does not produce any significant
> > > > > nor noticeable overhead as soon as the pool size is well set up.
> > > > >
> > > > > So i'm really confident.
> > > > > That said, the way singleton works with a READ lock is better in
> lots
> > > of
> > > > > cases (no instances to manage, no locks in the pool, less memory
> > > > > consumption, etc).
> > > > >
> > > > > But you are also right, it does not apply in any cases, I mean
> using
> > > > > stateless session beans is still relevant in some situations. Even
> > if I
> > > > > tend to preferably use Singleton, it's sometimes not applicable.
> > > > >
> > > > > Moreover you are right, EM is not thread safe as per the spec even
> if
> > > > some
> > > > > implementations (Hibernate for example) are in some situations. We
> > > > > discussed that point recently in the expert group as far as I
> recall.
> > > > >
> > > > > Hope it helps,
> > > > > Jean-Louis
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2013/3/13 zeeman <ha...@fastmail.us>
> > > > >
> > > > > > I have to disagree with some of the gurus here. In most cases a
> > > > stateless
> > > > > > or
> > > > > > singleton bean is going to use an entityManager/hibernate session
> > to
> > > > get
> > > > > > data to/from the DB. EM is not thread safe, using a singleton
> with
> > > read
> > > > > > lock
> > > > > > will cause concurrency issues on EM. So stateless in that case is
> > the
> > > > way
> > > > > > to
> > > > > > go as it'll have its own EM instance. For scalable applications
> > this
> > > > > would
> > > > > > work well.
> > > > > >
> > > > > > Having strict pooling = false with proper max/min values (based
> on
> > > > > expected
> > > > > > app load) will work as suggested.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > >
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> > > > > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jean-Louis
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Jean-Louis
> > >
> >
>
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Thanks... i'll stick with the 'far easier and definitely reliable' JavaEE,
and stay away from Spring as long as possible! :)
On Wed, Mar 13, 2013 at 10:54 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> spring is not wrong, i clearly think JavaEE is far easier for common needs
> + it doesnt prevent to use spring (spring data for instance)
>
> the thing to keep in mind is spring globally needs more technical knowledge
> because you basically do the container yourself
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/3/13 Howard W. Smith, Jr. <sm...@gmail.com>
>
> > Interesting conversation/facts/etc... here!
> >
> > singleton is basically the model that 'spring' propagated for years? wow
> > (shaking my head)... I purposely have avoided being or becoming a
> 'spring'
> > user and said to myself, Java EE 6 (reference implementation) clearly is
> > sufficient to meet any/all my Java EE needs. :)
> >
> > anyway, i am using @Singleton more and more in my app...thanks to advice
> > given by David Blevins months ago. :)
> >
> >
> > On Wed, Mar 13, 2013 at 4:46 AM, Romain Manni-Bucau
> > <rm...@gmail.com>wrote:
> >
> > > was no more clear for me ;)
> > >
> > > singleton is basically the model spring propagated for years and which
> is
> > > now known as very efficient
> > >
> > >
> > > *Romain Manni-Bucau*
> > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > http://rmannibucau.wordpress.com/>
> > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > *Github: https://github.com/rmannibucau*
> > >
> > >
> > >
> > > 2013/3/13 Jean-Louis MONTEIRO <je...@gmail.com>
> > >
> > > > I agree Romain, but it only works in that specific situation:
> > > > - EM type=TRANSACTION (not Extended)
> > > > - Java EE environment (not Java SE)
> > > >
> > > > And I also agree using a Singleton bean makes both true as it's not
> > > allowed
> > > > as per the spec to obtain an Extended PC in a Singleton.
> > > >
> > > > My purpose was just to try to get things clearer.
> > > >
> > > > Jean-Louis
> > > >
> > > >
> > > > 2013/3/13 Romain Manni-Bucau <rm...@gmail.com>
> > > >
> > > > > Em is clearly thread safe in a javaee envrt in transaction
> mode...at
> > > > least
> > > > > because of the transaction constraint you can get the same instance
> > in
> > > > > different threads
> > > > > Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <je...@gmail.com>
> a
> > > > écrit
> > > > > :
> > > > >
> > > > > > As a pure user feedback, we've been using OpenEJB/TomEE stateless
> > > beans
> > > > > on
> > > > > > huge applications and it does not produce any significant
> > > > > > nor noticeable overhead as soon as the pool size is well set up.
> > > > > >
> > > > > > So i'm really confident.
> > > > > > That said, the way singleton works with a READ lock is better in
> > lots
> > > > of
> > > > > > cases (no instances to manage, no locks in the pool, less memory
> > > > > > consumption, etc).
> > > > > >
> > > > > > But you are also right, it does not apply in any cases, I mean
> > using
> > > > > > stateless session beans is still relevant in some situations.
> Even
> > > if I
> > > > > > tend to preferably use Singleton, it's sometimes not applicable.
> > > > > >
> > > > > > Moreover you are right, EM is not thread safe as per the spec
> even
> > if
> > > > > some
> > > > > > implementations (Hibernate for example) are in some situations.
> We
> > > > > > discussed that point recently in the expert group as far as I
> > recall.
> > > > > >
> > > > > > Hope it helps,
> > > > > > Jean-Louis
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/3/13 zeeman <ha...@fastmail.us>
> > > > > >
> > > > > > > I have to disagree with some of the gurus here. In most cases a
> > > > > stateless
> > > > > > > or
> > > > > > > singleton bean is going to use an entityManager/hibernate
> session
> > > to
> > > > > get
> > > > > > > data to/from the DB. EM is not thread safe, using a singleton
> > with
> > > > read
> > > > > > > lock
> > > > > > > will cause concurrency issues on EM. So stateless in that case
> is
> > > the
> > > > > way
> > > > > > > to
> > > > > > > go as it'll have its own EM instance. For scalable applications
> > > this
> > > > > > would
> > > > > > > work well.
> > > > > > >
> > > > > > > Having strict pooling = false with proper max/min values (based
> > on
> > > > > > expected
> > > > > > > app load) will work as suggested.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > View this message in context:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> > > > > > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Jean-Louis
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Jean-Louis
> > > >
> > >
> >
>
Re: ConcurrentAccessTimeoutException
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
2013/3/13 Romain Manni-Bucau <rm...@gmail.com>
> the thing to keep in mind is spring globally needs more technical knowledge
> because you basically do the container yourself
>
Can't agree more ...
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
spring is not wrong, i clearly think JavaEE is far easier for common needs
+ it doesnt prevent to use spring (spring data for instance)
the thing to keep in mind is spring globally needs more technical knowledge
because you basically do the container yourself
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/13 Howard W. Smith, Jr. <sm...@gmail.com>
> Interesting conversation/facts/etc... here!
>
> singleton is basically the model that 'spring' propagated for years? wow
> (shaking my head)... I purposely have avoided being or becoming a 'spring'
> user and said to myself, Java EE 6 (reference implementation) clearly is
> sufficient to meet any/all my Java EE needs. :)
>
> anyway, i am using @Singleton more and more in my app...thanks to advice
> given by David Blevins months ago. :)
>
>
> On Wed, Mar 13, 2013 at 4:46 AM, Romain Manni-Bucau
> <rm...@gmail.com>wrote:
>
> > was no more clear for me ;)
> >
> > singleton is basically the model spring propagated for years and which is
> > now known as very efficient
> >
> >
> > *Romain Manni-Bucau*
> > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/3/13 Jean-Louis MONTEIRO <je...@gmail.com>
> >
> > > I agree Romain, but it only works in that specific situation:
> > > - EM type=TRANSACTION (not Extended)
> > > - Java EE environment (not Java SE)
> > >
> > > And I also agree using a Singleton bean makes both true as it's not
> > allowed
> > > as per the spec to obtain an Extended PC in a Singleton.
> > >
> > > My purpose was just to try to get things clearer.
> > >
> > > Jean-Louis
> > >
> > >
> > > 2013/3/13 Romain Manni-Bucau <rm...@gmail.com>
> > >
> > > > Em is clearly thread safe in a javaee envrt in transaction mode...at
> > > least
> > > > because of the transaction constraint you can get the same instance
> in
> > > > different threads
> > > > Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <je...@gmail.com> a
> > > écrit
> > > > :
> > > >
> > > > > As a pure user feedback, we've been using OpenEJB/TomEE stateless
> > beans
> > > > on
> > > > > huge applications and it does not produce any significant
> > > > > nor noticeable overhead as soon as the pool size is well set up.
> > > > >
> > > > > So i'm really confident.
> > > > > That said, the way singleton works with a READ lock is better in
> lots
> > > of
> > > > > cases (no instances to manage, no locks in the pool, less memory
> > > > > consumption, etc).
> > > > >
> > > > > But you are also right, it does not apply in any cases, I mean
> using
> > > > > stateless session beans is still relevant in some situations. Even
> > if I
> > > > > tend to preferably use Singleton, it's sometimes not applicable.
> > > > >
> > > > > Moreover you are right, EM is not thread safe as per the spec even
> if
> > > > some
> > > > > implementations (Hibernate for example) are in some situations. We
> > > > > discussed that point recently in the expert group as far as I
> recall.
> > > > >
> > > > > Hope it helps,
> > > > > Jean-Louis
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 2013/3/13 zeeman <ha...@fastmail.us>
> > > > >
> > > > > > I have to disagree with some of the gurus here. In most cases a
> > > > stateless
> > > > > > or
> > > > > > singleton bean is going to use an entityManager/hibernate session
> > to
> > > > get
> > > > > > data to/from the DB. EM is not thread safe, using a singleton
> with
> > > read
> > > > > > lock
> > > > > > will cause concurrency issues on EM. So stateless in that case is
> > the
> > > > way
> > > > > > to
> > > > > > go as it'll have its own EM instance. For scalable applications
> > this
> > > > > would
> > > > > > work well.
> > > > > >
> > > > > > Having strict pooling = false with proper max/min values (based
> on
> > > > > expected
> > > > > > app load) will work as suggested.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > >
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> > > > > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Jean-Louis
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Jean-Louis
> > >
> >
>
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Interesting conversation/facts/etc... here!
singleton is basically the model that 'spring' propagated for years? wow
(shaking my head)... I purposely have avoided being or becoming a 'spring'
user and said to myself, Java EE 6 (reference implementation) clearly is
sufficient to meet any/all my Java EE needs. :)
anyway, i am using @Singleton more and more in my app...thanks to advice
given by David Blevins months ago. :)
On Wed, Mar 13, 2013 at 4:46 AM, Romain Manni-Bucau
<rm...@gmail.com>wrote:
> was no more clear for me ;)
>
> singleton is basically the model spring propagated for years and which is
> now known as very efficient
>
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/3/13 Jean-Louis MONTEIRO <je...@gmail.com>
>
> > I agree Romain, but it only works in that specific situation:
> > - EM type=TRANSACTION (not Extended)
> > - Java EE environment (not Java SE)
> >
> > And I also agree using a Singleton bean makes both true as it's not
> allowed
> > as per the spec to obtain an Extended PC in a Singleton.
> >
> > My purpose was just to try to get things clearer.
> >
> > Jean-Louis
> >
> >
> > 2013/3/13 Romain Manni-Bucau <rm...@gmail.com>
> >
> > > Em is clearly thread safe in a javaee envrt in transaction mode...at
> > least
> > > because of the transaction constraint you can get the same instance in
> > > different threads
> > > Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <je...@gmail.com> a
> > écrit
> > > :
> > >
> > > > As a pure user feedback, we've been using OpenEJB/TomEE stateless
> beans
> > > on
> > > > huge applications and it does not produce any significant
> > > > nor noticeable overhead as soon as the pool size is well set up.
> > > >
> > > > So i'm really confident.
> > > > That said, the way singleton works with a READ lock is better in lots
> > of
> > > > cases (no instances to manage, no locks in the pool, less memory
> > > > consumption, etc).
> > > >
> > > > But you are also right, it does not apply in any cases, I mean using
> > > > stateless session beans is still relevant in some situations. Even
> if I
> > > > tend to preferably use Singleton, it's sometimes not applicable.
> > > >
> > > > Moreover you are right, EM is not thread safe as per the spec even if
> > > some
> > > > implementations (Hibernate for example) are in some situations. We
> > > > discussed that point recently in the expert group as far as I recall.
> > > >
> > > > Hope it helps,
> > > > Jean-Louis
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 2013/3/13 zeeman <ha...@fastmail.us>
> > > >
> > > > > I have to disagree with some of the gurus here. In most cases a
> > > stateless
> > > > > or
> > > > > singleton bean is going to use an entityManager/hibernate session
> to
> > > get
> > > > > data to/from the DB. EM is not thread safe, using a singleton with
> > read
> > > > > lock
> > > > > will cause concurrency issues on EM. So stateless in that case is
> the
> > > way
> > > > > to
> > > > > go as it'll have its own EM instance. For scalable applications
> this
> > > > would
> > > > > work well.
> > > > >
> > > > > Having strict pooling = false with proper max/min values (based on
> > > > expected
> > > > > app load) will work as suggested.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> > > > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Jean-Louis
> > > >
> > >
> >
> >
> >
> > --
> > Jean-Louis
> >
>
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
was no more clear for me ;)
singleton is basically the model spring propagated for years and which is
now known as very efficient
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/13 Jean-Louis MONTEIRO <je...@gmail.com>
> I agree Romain, but it only works in that specific situation:
> - EM type=TRANSACTION (not Extended)
> - Java EE environment (not Java SE)
>
> And I also agree using a Singleton bean makes both true as it's not allowed
> as per the spec to obtain an Extended PC in a Singleton.
>
> My purpose was just to try to get things clearer.
>
> Jean-Louis
>
>
> 2013/3/13 Romain Manni-Bucau <rm...@gmail.com>
>
> > Em is clearly thread safe in a javaee envrt in transaction mode...at
> least
> > because of the transaction constraint you can get the same instance in
> > different threads
> > Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <je...@gmail.com> a
> écrit
> > :
> >
> > > As a pure user feedback, we've been using OpenEJB/TomEE stateless beans
> > on
> > > huge applications and it does not produce any significant
> > > nor noticeable overhead as soon as the pool size is well set up.
> > >
> > > So i'm really confident.
> > > That said, the way singleton works with a READ lock is better in lots
> of
> > > cases (no instances to manage, no locks in the pool, less memory
> > > consumption, etc).
> > >
> > > But you are also right, it does not apply in any cases, I mean using
> > > stateless session beans is still relevant in some situations. Even if I
> > > tend to preferably use Singleton, it's sometimes not applicable.
> > >
> > > Moreover you are right, EM is not thread safe as per the spec even if
> > some
> > > implementations (Hibernate for example) are in some situations. We
> > > discussed that point recently in the expert group as far as I recall.
> > >
> > > Hope it helps,
> > > Jean-Louis
> > >
> > >
> > >
> > >
> > >
> > >
> > > 2013/3/13 zeeman <ha...@fastmail.us>
> > >
> > > > I have to disagree with some of the gurus here. In most cases a
> > stateless
> > > > or
> > > > singleton bean is going to use an entityManager/hibernate session to
> > get
> > > > data to/from the DB. EM is not thread safe, using a singleton with
> read
> > > > lock
> > > > will cause concurrency issues on EM. So stateless in that case is the
> > way
> > > > to
> > > > go as it'll have its own EM instance. For scalable applications this
> > > would
> > > > work well.
> > > >
> > > > Having strict pooling = false with proper max/min values (based on
> > > expected
> > > > app load) will work as suggested.
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> > > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > > >
> > >
> > >
> > >
> > > --
> > > Jean-Louis
> > >
> >
>
>
>
> --
> Jean-Louis
>
Re: ConcurrentAccessTimeoutException
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
I agree Romain, but it only works in that specific situation:
- EM type=TRANSACTION (not Extended)
- Java EE environment (not Java SE)
And I also agree using a Singleton bean makes both true as it's not allowed
as per the spec to obtain an Extended PC in a Singleton.
My purpose was just to try to get things clearer.
Jean-Louis
2013/3/13 Romain Manni-Bucau <rm...@gmail.com>
> Em is clearly thread safe in a javaee envrt in transaction mode...at least
> because of the transaction constraint you can get the same instance in
> different threads
> Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <je...@gmail.com> a écrit
> :
>
> > As a pure user feedback, we've been using OpenEJB/TomEE stateless beans
> on
> > huge applications and it does not produce any significant
> > nor noticeable overhead as soon as the pool size is well set up.
> >
> > So i'm really confident.
> > That said, the way singleton works with a READ lock is better in lots of
> > cases (no instances to manage, no locks in the pool, less memory
> > consumption, etc).
> >
> > But you are also right, it does not apply in any cases, I mean using
> > stateless session beans is still relevant in some situations. Even if I
> > tend to preferably use Singleton, it's sometimes not applicable.
> >
> > Moreover you are right, EM is not thread safe as per the spec even if
> some
> > implementations (Hibernate for example) are in some situations. We
> > discussed that point recently in the expert group as far as I recall.
> >
> > Hope it helps,
> > Jean-Louis
> >
> >
> >
> >
> >
> >
> > 2013/3/13 zeeman <ha...@fastmail.us>
> >
> > > I have to disagree with some of the gurus here. In most cases a
> stateless
> > > or
> > > singleton bean is going to use an entityManager/hibernate session to
> get
> > > data to/from the DB. EM is not thread safe, using a singleton with read
> > > lock
> > > will cause concurrency issues on EM. So stateless in that case is the
> way
> > > to
> > > go as it'll have its own EM instance. For scalable applications this
> > would
> > > work well.
> > >
> > > Having strict pooling = false with proper max/min values (based on
> > expected
> > > app load) will work as suggested.
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > >
> >
> >
> >
> > --
> > Jean-Louis
> >
>
--
Jean-Louis
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Em is clearly thread safe in a javaee envrt in transaction mode...at least
because of the transaction constraint you can get the same instance in
different threads
Le 13 mars 2013 08:40, "Jean-Louis MONTEIRO" <je...@gmail.com> a écrit :
> As a pure user feedback, we've been using OpenEJB/TomEE stateless beans on
> huge applications and it does not produce any significant
> nor noticeable overhead as soon as the pool size is well set up.
>
> So i'm really confident.
> That said, the way singleton works with a READ lock is better in lots of
> cases (no instances to manage, no locks in the pool, less memory
> consumption, etc).
>
> But you are also right, it does not apply in any cases, I mean using
> stateless session beans is still relevant in some situations. Even if I
> tend to preferably use Singleton, it's sometimes not applicable.
>
> Moreover you are right, EM is not thread safe as per the spec even if some
> implementations (Hibernate for example) are in some situations. We
> discussed that point recently in the expert group as far as I recall.
>
> Hope it helps,
> Jean-Louis
>
>
>
>
>
>
> 2013/3/13 zeeman <ha...@fastmail.us>
>
> > I have to disagree with some of the gurus here. In most cases a stateless
> > or
> > singleton bean is going to use an entityManager/hibernate session to get
> > data to/from the DB. EM is not thread safe, using a singleton with read
> > lock
> > will cause concurrency issues on EM. So stateless in that case is the way
> > to
> > go as it'll have its own EM instance. For scalable applications this
> would
> > work well.
> >
> > Having strict pooling = false with proper max/min values (based on
> expected
> > app load) will work as suggested.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
>
>
>
> --
> Jean-Louis
>
Re: ConcurrentAccessTimeoutException
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
As a pure user feedback, we've been using OpenEJB/TomEE stateless beans on
huge applications and it does not produce any significant
nor noticeable overhead as soon as the pool size is well set up.
So i'm really confident.
That said, the way singleton works with a READ lock is better in lots of
cases (no instances to manage, no locks in the pool, less memory
consumption, etc).
But you are also right, it does not apply in any cases, I mean using
stateless session beans is still relevant in some situations. Even if I
tend to preferably use Singleton, it's sometimes not applicable.
Moreover you are right, EM is not thread safe as per the spec even if some
implementations (Hibernate for example) are in some situations. We
discussed that point recently in the expert group as far as I recall.
Hope it helps,
Jean-Louis
2013/3/13 zeeman <ha...@fastmail.us>
> I have to disagree with some of the gurus here. In most cases a stateless
> or
> singleton bean is going to use an entityManager/hibernate session to get
> data to/from the DB. EM is not thread safe, using a singleton with read
> lock
> will cause concurrency issues on EM. So stateless in that case is the way
> to
> go as it'll have its own EM instance. For scalable applications this would
> work well.
>
> Having strict pooling = false with proper max/min values (based on expected
> app load) will work as suggested.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
--
Jean-Louis
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
If you develop your singleton as a stateless it should be thread safe...and
about entities you cant get the same instance, just the same value which is
the same as for stateless.
Le 13 mars 2013 03:32, "zeeman" <ha...@fastmail.us> a écrit :
> How come all documentation I read does not say EM is thread safe at all? EM
> with transactional type is the default type right?
>
> Even in that case, if 2 threads try to update or read the same entity there
> is a chance of data corruption because the lock is readOnly. Not sure how
> would that affect isolation level and optimistic locking.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661471.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: ConcurrentAccessTimeoutException
Posted by zeeman <ha...@fastmail.us>.
How come all documentation I read does not say EM is thread safe at all? EM
with transactional type is the default type right?
Even in that case, if 2 threads try to update or read the same entity there
is a chance of data corruption because the lock is readOnly. Not sure how
would that affect isolation level and optimistic locking.
--
View this message in context: http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661471.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
em is thread safe when its type is transaction
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
2013/3/13 zeeman <ha...@fastmail.us>
> I have to disagree with some of the gurus here. In most cases a stateless
> or
> singleton bean is going to use an entityManager/hibernate session to get
> data to/from the DB. EM is not thread safe, using a singleton with read
> lock
> will cause concurrency issues on EM. So stateless in that case is the way
> to
> go as it'll have its own EM instance. For scalable applications this would
> work well.
>
> Having strict pooling = false with proper max/min values (based on expected
> app load) will work as suggested.
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
Re: ConcurrentAccessTimeoutException
Posted by zeeman <ha...@fastmail.us>.
I have to disagree with some of the gurus here. In most cases a stateless or
singleton bean is going to use an entityManager/hibernate session to get
data to/from the DB. EM is not thread safe, using a singleton with read lock
will cause concurrency issues on EM. So stateless in that case is the way to
go as it'll have its own EM instance. For scalable applications this would
work well.
Having strict pooling = false with proper max/min values (based on expected
app load) will work as suggested.
--
View this message in context: http://openejb.979440.n4.nabble.com/ConcurrentAccessTimeoutException-tp4661288p4661466.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
I've learned that Google calendar API delete event method is not reliable,
so other people advised that it is best to loop a few times to ensure all
events are deleted. I only loop until the events are deleted.
Also, I had to add a request counter. After every 3 requests, i do a while
true until 5 seconds later (using joda time library), reset request
counter, and continue processing. That method is called before every delete
or add request. That method also checks if last request was more than 5
seconds ago; if more than 5 seconds ago, then no need to while true for 5
seconds.
All of this was added within the last week and contributed to the solution
of the duplicates issue. ActiveMQ/MDB was only added, so user don't have to
wait for Google Calendar to be updated.
The stack is really fast; seem to take seconds to update. I'm seeing no
more duplicates on the dates that have many events.
Still loving TomEE! I consideted ActiveMQ some time ago but finally decided
to give it a go and was quite easy to add, all because of TomEE. :-)
I get motivated by listening to other people questions, so I'm glad someone
asked about ActiveMQ in TomEE, recently.
On Mar 12, 2013 3:40 AM, "James Green" <ja...@gmail.com> wrote:
> Obvious question: if Google rate-limited you, how did you end up posting
> duplicates?
>
>
>
> On 12 March 2013 01:57, Howard W. Smith, Jr. <sm...@gmail.com>
> wrote:
>
> > Wanted to share...
> >
> > 1. I recently added ActiveMQ logic and dependency (TomEE's simple MDB
> > example) to update Google Calendar with data from database as user is in
> > web app modifying data; the non-MDB logic worked, but duplicates existed
> on
> > the Google Calendar, since Google Calendar has limits on # of requests
> per
> > user (within a matter of seconds)
> >
> > 2. The new simple MDB implementation resulted in many more duplicate
> events
> > on the Google Calendar, since messages were processed, asynchronously
> >
> > 3. This morning, I (FINALLY) fixed the 'duplicate events issue' by
> marking
> > the GoogleCalendarUtil bean as @Singleton with @Lock(WRITE), adding one
> > point of entry (deleteAndAddEvents method marked with @AccessTimeout),
> > defined 'deleteEvents' and 'addEventToCalendar' method as private (since
> > they were defined as 'public' methods, ever since 'birth'), and
> refactored
> > throughout the app, accordingly.
> >
> > Was this the most appropriate fix? Probably not, but I was happy to
> develop
> > some code based on recommendation(s) that David Blevins shared months
> ago.
> > :)
> >
> >
> >
> > On Fri, Mar 8, 2013 at 9:25 AM, Howard W. Smith, Jr. <
> > smithh032772@gmail.com
> > > wrote:
> >
> > > +1 to any/all David Blevin's responses...and of course, the same for
> all
> > > of Romain's responses as well!
> > >
> > > Just to share... I remember I used to see a bunch of LOCK exceptions in
> > > server log with @Singleton after David advised me to use @Singleton,
> but
> > I
> > > kept tuning the implementation. Now, I have not seen those exceptions
> any
> > > more in server log. I don't know if it was just a TomEE 1.5.1 bug that
> > got
> > > fixed in 1.5.2-SNAPSHOT, but recently, I decreased the # of minutes on
> > the
> > > @Schedule method defined on the only 2 @Singleton beans I have, and
> > still,
> > > it is performing (very) well and no exceptions in server log.
> > >
> > > I know this may be a bit unrelated, but still thought I might share.
> I'm
> > > hoping to add more @Singleton for @Schedule tasks.
> > >
> > > My code has been working well with @Stateless for the design, which is
> > > evident when web application code is generated by NetBeans from
> database
> > > schema.
> > >
> > > Entity bean > @Stateless EJB for the entity bean > JSF managed bean
> which
> > > references @Stateless EJB and entity bean > xhtml page, which
> references
> > > the JSF managed bean
> > >
> > > Of course, I have done refactoring to meet requirements. :)
> > >
> > > This design/implementation has worked for me, in production, while the
> > app
> > > was running on Glassfish 3.1+ and now with TomEE.
> > >
> > >
> > > On Thu, Mar 7, 2013 at 7:10 PM, David Blevins <david.blevins@gmail.com
> > >wrote:
> > >
> > >> I'd also recommend @Singleton in conjunction with @Lock(READ).
> > >>
> > >> The @Stateless bean type is good when you explicitly need to limit the
> > >> number of instances/concurrent calls. If this sort of limiting is
> not a
> > >> critical part of the design, then likely @Stateless was used because
> > this
> > >> is the bean type people tend to use by default.
> > >>
> > >> Really, @Singleton with @Lock(READ) should be used by default and
> other
> > >> bean types used only when there is a specific design goal you need to
> > >> achieve.
> > >>
> > >>
> > >> -David
> > >>
> > >> On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > >> wrote:
> > >>
> > >> > In very very heavy load and for a simple app it can be as much as
> your
> > >> http
> > >> > request thread pool size (200 by default)
> > >> >
> > >> > Note: using @Singleton can help too if you can
> > >> > Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a
> > >> écrit :
> > >> >
> > >> >> Really im not sure how many users the webapp could handle, because
> > is a
> > >> >> public webapp, i will increase the MaxSize to 50 or 100, but for
> any
> > >> >> "unexpected
> > >> >> overload" i will let StrictPooling to false.
> > >> >>
> > >> >> Do you consider its to much to increase to 50/100 to maxsize??
> > >> >>
> > >> >>
> > >> >>
> > >> >> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
> > >> >>
> > >> >>> José,
> > >> >>>
> > >> >>> The MinSize is not the problem IMO.
> > >> >>> The MaxSize is definitely the issue. Do you have more than 10
> > (default
> > >> >>> value) simultaneous users?
> > >> >>>
> > >> >>> The StrictPooling is great to be able to always answer in case of
> > >> small
> > >> >>> over load.
> > >> >>> But, you have to know that after being used, instances will be
> > removed
> > >> >> and
> > >> >>> garbage collected.
> > >> >>>
> > >> >>> Also, creating instances can be consuming depending on the bean.
> > >> >>>
> > >> >>> I would recommend not only to set it to true, but before, trying
> to
> > >> >> define
> > >> >>> as much as possible the correct value for MaxSize depending on
> your
> > >> SLAs.
> > >> >>>
> > >> >>> Hope it helps
> > >> >>> JLouis
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
> > >> >>>
> > >> >>>> Im using 1.6.0-SNAPSHOT.
> > >> >>>>
> > >> >>>> I will change
> > >> >>>>
> > >> >>>> StrictPooling = true ==> false
> > >> >>>> MinSize = 0 ==> 2
> > >> >>>>
> > >> >>>> In stateless section and let you know.
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> > >> >>>>
> > >> >>>>> José,
> > >> >>>>>
> > >> >>>>> I'm sure the others will ask, are you seeing this with tomee
> 1.5.2
> > >> or
> > >> >>>> 1.6.0
> > >> >>>>> snapshot? or only seeing on your production server running
> tomee
> > >> >> 1.5.1
> > >> >>>> or
> > >> >>>>> 1.5.2 / 1.6.0 snapshot?
> > >> >>>>>
> > >> >>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> > >> >>>>>
> > >> >>>>> Also, i searched google for the following:
> > >> >>>>>
> > >> >>>>> No instances available in Stateless Session Bean pool
> > >> >>>>>
> > >> >>>>> and found the following (which is definitely related to
> Jean-Louis
> > >> >>>>> response):
> > >> >>>>>
> > >> >>>>> [1]
> > >> >>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> > >> >>>>>
> > >> >>>>> [2]
> > >> >>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> > >> >>>>>
> > >> >>>>> [3]
> > >> http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> Howard
> > >> >>>>>
> > >> >>>>>
> > >> >>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> > >> >>> maxtorzito@gmail.com
> > >> >>>>>> wrote:
> > >> >>>>>
> > >> >>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
> > >> >>> available
> > >> >>>> in
> > >> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
> > >> >>>>>>
> > >> >>>>>> Here is the complete log: http://pastebin.ca/2328770
> > >> >>>>>>
> > >> >>>>>> Any advice, what could be? Do i have to configure something in
> > >> >>>>> tomee.xml??
> > >> >>>>>>
> > >> >>>>>> Part of the log:
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>> *Mar 05, 2013 9:38:20 PM
> > >> >> org.apache.openejb.cdi.CdiAppContextsService
> > >> >>>>>> lazyStartSessionContext
> > >> >>>>>> WARNING: Could NOT lazily initialize session context because of
> > >> >> null
> > >> >>>>>> RequestContext
> > >> >>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances
> > available
> > >> >> in
> > >> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> > >> >>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> > >> >>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown
> Source)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > >> >>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> > >> >>>>>> at
> > >> >> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> > >> >>>>>> at
> > >> >> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> > >> >>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> > >> >>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> > >> >>>>>> at
> > >> >>>>>
> > >> >>>
> > >>
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> > >> >>>>>> at
> > >> >>>>>
> > >> >>>
> > >>
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>
> > >> >>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>
> > >> >>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>
> > >> >>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>
> > >> >>
> > >>
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>
> > >> >>
> > >>
> > org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> > >> >>>>>> at
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> > >> >>>>>> at
> > >> >>>
> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>
> > >> >>
> > >>
> > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> > >> >>>>>> at
> > >> >> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > >> >>>>>> at
> > >> >>>>>>
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>
> > >> >>
> > >>
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > >> >>>>>> at java.lang.Thread.run(Thread.java:722)
> > >> >>>>>> *
> > >> >>>>>>
> > >> >>>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> --
> > >> >>>>
> -------------------------------------------------------------------
> > >> >>>> *SCJA. José Luis Cetina*
> > >> >>>>
> -------------------------------------------------------------------
> > >> >>>>
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> --
> > >> >>> Jean-Louis
> > >> >>>
> > >> >>
> > >> >>
> > >> >>
> > >> >> --
> > >> >> -------------------------------------------------------------------
> > >> >> *SCJA. José Luis Cetina*
> > >> >> -------------------------------------------------------------------
> > >> >>
> > >>
> > >>
> > >
> >
>
Re: ConcurrentAccessTimeoutException
Posted by James Green <ja...@gmail.com>.
Obvious question: if Google rate-limited you, how did you end up posting
duplicates?
On 12 March 2013 01:57, Howard W. Smith, Jr. <sm...@gmail.com> wrote:
> Wanted to share...
>
> 1. I recently added ActiveMQ logic and dependency (TomEE's simple MDB
> example) to update Google Calendar with data from database as user is in
> web app modifying data; the non-MDB logic worked, but duplicates existed on
> the Google Calendar, since Google Calendar has limits on # of requests per
> user (within a matter of seconds)
>
> 2. The new simple MDB implementation resulted in many more duplicate events
> on the Google Calendar, since messages were processed, asynchronously
>
> 3. This morning, I (FINALLY) fixed the 'duplicate events issue' by marking
> the GoogleCalendarUtil bean as @Singleton with @Lock(WRITE), adding one
> point of entry (deleteAndAddEvents method marked with @AccessTimeout),
> defined 'deleteEvents' and 'addEventToCalendar' method as private (since
> they were defined as 'public' methods, ever since 'birth'), and refactored
> throughout the app, accordingly.
>
> Was this the most appropriate fix? Probably not, but I was happy to develop
> some code based on recommendation(s) that David Blevins shared months ago.
> :)
>
>
>
> On Fri, Mar 8, 2013 at 9:25 AM, Howard W. Smith, Jr. <
> smithh032772@gmail.com
> > wrote:
>
> > +1 to any/all David Blevin's responses...and of course, the same for all
> > of Romain's responses as well!
> >
> > Just to share... I remember I used to see a bunch of LOCK exceptions in
> > server log with @Singleton after David advised me to use @Singleton, but
> I
> > kept tuning the implementation. Now, I have not seen those exceptions any
> > more in server log. I don't know if it was just a TomEE 1.5.1 bug that
> got
> > fixed in 1.5.2-SNAPSHOT, but recently, I decreased the # of minutes on
> the
> > @Schedule method defined on the only 2 @Singleton beans I have, and
> still,
> > it is performing (very) well and no exceptions in server log.
> >
> > I know this may be a bit unrelated, but still thought I might share. I'm
> > hoping to add more @Singleton for @Schedule tasks.
> >
> > My code has been working well with @Stateless for the design, which is
> > evident when web application code is generated by NetBeans from database
> > schema.
> >
> > Entity bean > @Stateless EJB for the entity bean > JSF managed bean which
> > references @Stateless EJB and entity bean > xhtml page, which references
> > the JSF managed bean
> >
> > Of course, I have done refactoring to meet requirements. :)
> >
> > This design/implementation has worked for me, in production, while the
> app
> > was running on Glassfish 3.1+ and now with TomEE.
> >
> >
> > On Thu, Mar 7, 2013 at 7:10 PM, David Blevins <david.blevins@gmail.com
> >wrote:
> >
> >> I'd also recommend @Singleton in conjunction with @Lock(READ).
> >>
> >> The @Stateless bean type is good when you explicitly need to limit the
> >> number of instances/concurrent calls. If this sort of limiting is not a
> >> critical part of the design, then likely @Stateless was used because
> this
> >> is the bean type people tend to use by default.
> >>
> >> Really, @Singleton with @Lock(READ) should be used by default and other
> >> bean types used only when there is a specific design goal you need to
> >> achieve.
> >>
> >>
> >> -David
> >>
> >> On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <rm...@gmail.com>
> >> wrote:
> >>
> >> > In very very heavy load and for a simple app it can be as much as your
> >> http
> >> > request thread pool size (200 by default)
> >> >
> >> > Note: using @Singleton can help too if you can
> >> > Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a
> >> écrit :
> >> >
> >> >> Really im not sure how many users the webapp could handle, because
> is a
> >> >> public webapp, i will increase the MaxSize to 50 or 100, but for any
> >> >> "unexpected
> >> >> overload" i will let StrictPooling to false.
> >> >>
> >> >> Do you consider its to much to increase to 50/100 to maxsize??
> >> >>
> >> >>
> >> >>
> >> >> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
> >> >>
> >> >>> José,
> >> >>>
> >> >>> The MinSize is not the problem IMO.
> >> >>> The MaxSize is definitely the issue. Do you have more than 10
> (default
> >> >>> value) simultaneous users?
> >> >>>
> >> >>> The StrictPooling is great to be able to always answer in case of
> >> small
> >> >>> over load.
> >> >>> But, you have to know that after being used, instances will be
> removed
> >> >> and
> >> >>> garbage collected.
> >> >>>
> >> >>> Also, creating instances can be consuming depending on the bean.
> >> >>>
> >> >>> I would recommend not only to set it to true, but before, trying to
> >> >> define
> >> >>> as much as possible the correct value for MaxSize depending on your
> >> SLAs.
> >> >>>
> >> >>> Hope it helps
> >> >>> JLouis
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
> >> >>>
> >> >>>> Im using 1.6.0-SNAPSHOT.
> >> >>>>
> >> >>>> I will change
> >> >>>>
> >> >>>> StrictPooling = true ==> false
> >> >>>> MinSize = 0 ==> 2
> >> >>>>
> >> >>>> In stateless section and let you know.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> >> >>>>
> >> >>>>> José,
> >> >>>>>
> >> >>>>> I'm sure the others will ask, are you seeing this with tomee 1.5.2
> >> or
> >> >>>> 1.6.0
> >> >>>>> snapshot? or only seeing on your production server running tomee
> >> >> 1.5.1
> >> >>>> or
> >> >>>>> 1.5.2 / 1.6.0 snapshot?
> >> >>>>>
> >> >>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> >> >>>>>
> >> >>>>> Also, i searched google for the following:
> >> >>>>>
> >> >>>>> No instances available in Stateless Session Bean pool
> >> >>>>>
> >> >>>>> and found the following (which is definitely related to Jean-Louis
> >> >>>>> response):
> >> >>>>>
> >> >>>>> [1]
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> >> >>>>>
> >> >>>>> [2]
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> >> >>>>>
> >> >>>>> [3]
> >> http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> >> >>>>>
> >> >>>>>
> >> >>>>> Howard
> >> >>>>>
> >> >>>>>
> >> >>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> >> >>> maxtorzito@gmail.com
> >> >>>>>> wrote:
> >> >>>>>
> >> >>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
> >> >>> available
> >> >>>> in
> >> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
> >> >>>>>>
> >> >>>>>> Here is the complete log: http://pastebin.ca/2328770
> >> >>>>>>
> >> >>>>>> Any advice, what could be? Do i have to configure something in
> >> >>>>> tomee.xml??
> >> >>>>>>
> >> >>>>>> Part of the log:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> *Mar 05, 2013 9:38:20 PM
> >> >> org.apache.openejb.cdi.CdiAppContextsService
> >> >>>>>> lazyStartSessionContext
> >> >>>>>> WARNING: Could NOT lazily initialize session context because of
> >> >> null
> >> >>>>>> RequestContext
> >> >>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances
> available
> >> >> in
> >> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> >> >>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> >> >>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >> >>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> >> >>>>>> at
> >> >> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> >> >>>>>> at
> >> >> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> >> >>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> >> >>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> >> >>>>>> at
> >> >>>>>
> >> >>>
> >> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> >> >>>>>> at
> >> >>>>>
> >> >>>
> >> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> >> >>>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> >> >>>>>> at
> >> >>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>
> >> >>
> >>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> >> >>>>>> at
> >> >> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >> >>>>>> at
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>
> >> >>
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >> >>>>>> at java.lang.Thread.run(Thread.java:722)
> >> >>>>>> *
> >> >>>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> --
> >> >>>> -------------------------------------------------------------------
> >> >>>> *SCJA. José Luis Cetina*
> >> >>>> -------------------------------------------------------------------
> >> >>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Jean-Louis
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> -------------------------------------------------------------------
> >> >> *SCJA. José Luis Cetina*
> >> >> -------------------------------------------------------------------
> >> >>
> >>
> >>
> >
>
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Wanted to share...
1. I recently added ActiveMQ logic and dependency (TomEE's simple MDB
example) to update Google Calendar with data from database as user is in
web app modifying data; the non-MDB logic worked, but duplicates existed on
the Google Calendar, since Google Calendar has limits on # of requests per
user (within a matter of seconds)
2. The new simple MDB implementation resulted in many more duplicate events
on the Google Calendar, since messages were processed, asynchronously
3. This morning, I (FINALLY) fixed the 'duplicate events issue' by marking
the GoogleCalendarUtil bean as @Singleton with @Lock(WRITE), adding one
point of entry (deleteAndAddEvents method marked with @AccessTimeout),
defined 'deleteEvents' and 'addEventToCalendar' method as private (since
they were defined as 'public' methods, ever since 'birth'), and refactored
throughout the app, accordingly.
Was this the most appropriate fix? Probably not, but I was happy to develop
some code based on recommendation(s) that David Blevins shared months ago.
:)
On Fri, Mar 8, 2013 at 9:25 AM, Howard W. Smith, Jr. <smithh032772@gmail.com
> wrote:
> +1 to any/all David Blevin's responses...and of course, the same for all
> of Romain's responses as well!
>
> Just to share... I remember I used to see a bunch of LOCK exceptions in
> server log with @Singleton after David advised me to use @Singleton, but I
> kept tuning the implementation. Now, I have not seen those exceptions any
> more in server log. I don't know if it was just a TomEE 1.5.1 bug that got
> fixed in 1.5.2-SNAPSHOT, but recently, I decreased the # of minutes on the
> @Schedule method defined on the only 2 @Singleton beans I have, and still,
> it is performing (very) well and no exceptions in server log.
>
> I know this may be a bit unrelated, but still thought I might share. I'm
> hoping to add more @Singleton for @Schedule tasks.
>
> My code has been working well with @Stateless for the design, which is
> evident when web application code is generated by NetBeans from database
> schema.
>
> Entity bean > @Stateless EJB for the entity bean > JSF managed bean which
> references @Stateless EJB and entity bean > xhtml page, which references
> the JSF managed bean
>
> Of course, I have done refactoring to meet requirements. :)
>
> This design/implementation has worked for me, in production, while the app
> was running on Glassfish 3.1+ and now with TomEE.
>
>
> On Thu, Mar 7, 2013 at 7:10 PM, David Blevins <da...@gmail.com>wrote:
>
>> I'd also recommend @Singleton in conjunction with @Lock(READ).
>>
>> The @Stateless bean type is good when you explicitly need to limit the
>> number of instances/concurrent calls. If this sort of limiting is not a
>> critical part of the design, then likely @Stateless was used because this
>> is the bean type people tend to use by default.
>>
>> Really, @Singleton with @Lock(READ) should be used by default and other
>> bean types used only when there is a specific design goal you need to
>> achieve.
>>
>>
>> -David
>>
>> On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <rm...@gmail.com>
>> wrote:
>>
>> > In very very heavy load and for a simple app it can be as much as your
>> http
>> > request thread pool size (200 by default)
>> >
>> > Note: using @Singleton can help too if you can
>> > Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a
>> écrit :
>> >
>> >> Really im not sure how many users the webapp could handle, because is a
>> >> public webapp, i will increase the MaxSize to 50 or 100, but for any
>> >> "unexpected
>> >> overload" i will let StrictPooling to false.
>> >>
>> >> Do you consider its to much to increase to 50/100 to maxsize??
>> >>
>> >>
>> >>
>> >> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
>> >>
>> >>> José,
>> >>>
>> >>> The MinSize is not the problem IMO.
>> >>> The MaxSize is definitely the issue. Do you have more than 10 (default
>> >>> value) simultaneous users?
>> >>>
>> >>> The StrictPooling is great to be able to always answer in case of
>> small
>> >>> over load.
>> >>> But, you have to know that after being used, instances will be removed
>> >> and
>> >>> garbage collected.
>> >>>
>> >>> Also, creating instances can be consuming depending on the bean.
>> >>>
>> >>> I would recommend not only to set it to true, but before, trying to
>> >> define
>> >>> as much as possible the correct value for MaxSize depending on your
>> SLAs.
>> >>>
>> >>> Hope it helps
>> >>> JLouis
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
>> >>>
>> >>>> Im using 1.6.0-SNAPSHOT.
>> >>>>
>> >>>> I will change
>> >>>>
>> >>>> StrictPooling = true ==> false
>> >>>> MinSize = 0 ==> 2
>> >>>>
>> >>>> In stateless section and let you know.
>> >>>>
>> >>>>
>> >>>>
>> >>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
>> >>>>
>> >>>>> José,
>> >>>>>
>> >>>>> I'm sure the others will ask, are you seeing this with tomee 1.5.2
>> or
>> >>>> 1.6.0
>> >>>>> snapshot? or only seeing on your production server running tomee
>> >> 1.5.1
>> >>>> or
>> >>>>> 1.5.2 / 1.6.0 snapshot?
>> >>>>>
>> >>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
>> >>>>>
>> >>>>> Also, i searched google for the following:
>> >>>>>
>> >>>>> No instances available in Stateless Session Bean pool
>> >>>>>
>> >>>>> and found the following (which is definitely related to Jean-Louis
>> >>>>> response):
>> >>>>>
>> >>>>> [1]
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
>> >>>>>
>> >>>>> [2]
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
>> >>>>>
>> >>>>> [3]
>> http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
>> >>>>>
>> >>>>>
>> >>>>> Howard
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
>> >>> maxtorzito@gmail.com
>> >>>>>> wrote:
>> >>>>>
>> >>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
>> >>> available
>> >>>> in
>> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
>> >>>>>>
>> >>>>>> Here is the complete log: http://pastebin.ca/2328770
>> >>>>>>
>> >>>>>> Any advice, what could be? Do i have to configure something in
>> >>>>> tomee.xml??
>> >>>>>>
>> >>>>>> Part of the log:
>> >>>>>>
>> >>>>>>
>> >>>>>> *Mar 05, 2013 9:38:20 PM
>> >> org.apache.openejb.cdi.CdiAppContextsService
>> >>>>>> lazyStartSessionContext
>> >>>>>> WARNING: Could NOT lazily initialize session context because of
>> >> null
>> >>>>>> RequestContext
>> >>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances available
>> >> in
>> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
>> >>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
>> >>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
>> >>>>>> at
>> >> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
>> >>>>>> at
>> >> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
>> >>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
>> >>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
>> >>>>>> at
>> >>>>>
>> >>>
>> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
>> >>>>>> at
>> >>>>>
>> >>>
>> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
>> >>>>>> at
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
>> >>>>>> at
>> >>>>>>
>> >>>>
>> >>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
>> >>>>>> at
>> >>>>>>
>> >>>>
>> >>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
>> >>>>>> at
>> >>>>>>
>> >>>>
>> >>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
>> >>>>>> at
>> >>>>>>
>> >>>>
>> >>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
>> >>>>>> at
>> >>>>>>
>> >>>>
>> >>
>> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
>> >>>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>> >>>>>> at
>> >>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
>> >>>>>> at
>> >>>>>>
>> >>>>
>> >>
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>> >>>>>> at
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
>> >>>>>> at
>> >> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> >>>>>> at
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> >>>>>> at java.lang.Thread.run(Thread.java:722)
>> >>>>>> *
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> -------------------------------------------------------------------
>> >>>> *SCJA. José Luis Cetina*
>> >>>> -------------------------------------------------------------------
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Jean-Louis
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> -------------------------------------------------------------------
>> >> *SCJA. José Luis Cetina*
>> >> -------------------------------------------------------------------
>> >>
>>
>>
>
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
+1 to any/all David Blevin's responses...and of course, the same for all of
Romain's responses as well!
Just to share... I remember I used to see a bunch of LOCK exceptions in
server log with @Singleton after David advised me to use @Singleton, but I
kept tuning the implementation. Now, I have not seen those exceptions any
more in server log. I don't know if it was just a TomEE 1.5.1 bug that got
fixed in 1.5.2-SNAPSHOT, but recently, I decreased the # of minutes on the
@Schedule method defined on the only 2 @Singleton beans I have, and still,
it is performing (very) well and no exceptions in server log.
I know this may be a bit unrelated, but still thought I might share. I'm
hoping to add more @Singleton for @Schedule tasks.
My code has been working well with @Stateless for the design, which is
evident when web application code is generated by NetBeans from database
schema.
Entity bean > @Stateless EJB for the entity bean > JSF managed bean which
references @Stateless EJB and entity bean > xhtml page, which references
the JSF managed bean
Of course, I have done refactoring to meet requirements. :)
This design/implementation has worked for me, in production, while the app
was running on Glassfish 3.1+ and now with TomEE.
On Thu, Mar 7, 2013 at 7:10 PM, David Blevins <da...@gmail.com>wrote:
> I'd also recommend @Singleton in conjunction with @Lock(READ).
>
> The @Stateless bean type is good when you explicitly need to limit the
> number of instances/concurrent calls. If this sort of limiting is not a
> critical part of the design, then likely @Stateless was used because this
> is the bean type people tend to use by default.
>
> Really, @Singleton with @Lock(READ) should be used by default and other
> bean types used only when there is a specific design goal you need to
> achieve.
>
>
> -David
>
> On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > In very very heavy load and for a simple app it can be as much as your
> http
> > request thread pool size (200 by default)
> >
> > Note: using @Singleton can help too if you can
> > Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a écrit
> :
> >
> >> Really im not sure how many users the webapp could handle, because is a
> >> public webapp, i will increase the MaxSize to 50 or 100, but for any
> >> "unexpected
> >> overload" i will let StrictPooling to false.
> >>
> >> Do you consider its to much to increase to 50/100 to maxsize??
> >>
> >>
> >>
> >> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
> >>
> >>> José,
> >>>
> >>> The MinSize is not the problem IMO.
> >>> The MaxSize is definitely the issue. Do you have more than 10 (default
> >>> value) simultaneous users?
> >>>
> >>> The StrictPooling is great to be able to always answer in case of small
> >>> over load.
> >>> But, you have to know that after being used, instances will be removed
> >> and
> >>> garbage collected.
> >>>
> >>> Also, creating instances can be consuming depending on the bean.
> >>>
> >>> I would recommend not only to set it to true, but before, trying to
> >> define
> >>> as much as possible the correct value for MaxSize depending on your
> SLAs.
> >>>
> >>> Hope it helps
> >>> JLouis
> >>>
> >>>
> >>>
> >>>
> >>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
> >>>
> >>>> Im using 1.6.0-SNAPSHOT.
> >>>>
> >>>> I will change
> >>>>
> >>>> StrictPooling = true ==> false
> >>>> MinSize = 0 ==> 2
> >>>>
> >>>> In stateless section and let you know.
> >>>>
> >>>>
> >>>>
> >>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> >>>>
> >>>>> José,
> >>>>>
> >>>>> I'm sure the others will ask, are you seeing this with tomee 1.5.2 or
> >>>> 1.6.0
> >>>>> snapshot? or only seeing on your production server running tomee
> >> 1.5.1
> >>>> or
> >>>>> 1.5.2 / 1.6.0 snapshot?
> >>>>>
> >>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> >>>>>
> >>>>> Also, i searched google for the following:
> >>>>>
> >>>>> No instances available in Stateless Session Bean pool
> >>>>>
> >>>>> and found the following (which is definitely related to Jean-Louis
> >>>>> response):
> >>>>>
> >>>>> [1]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> >>>>>
> >>>>> [2]
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> >>>>>
> >>>>> [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> >>>>>
> >>>>>
> >>>>> Howard
> >>>>>
> >>>>>
> >>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> >>> maxtorzito@gmail.com
> >>>>>> wrote:
> >>>>>
> >>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
> >>> available
> >>>> in
> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
> >>>>>>
> >>>>>> Here is the complete log: http://pastebin.ca/2328770
> >>>>>>
> >>>>>> Any advice, what could be? Do i have to configure something in
> >>>>> tomee.xml??
> >>>>>>
> >>>>>> Part of the log:
> >>>>>>
> >>>>>>
> >>>>>> *Mar 05, 2013 9:38:20 PM
> >> org.apache.openejb.cdi.CdiAppContextsService
> >>>>>> lazyStartSessionContext
> >>>>>> WARNING: Could NOT lazily initialize session context because of
> >> null
> >>>>>> RequestContext
> >>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances available
> >> in
> >>>>>> Stateless Session Bean pool. Waited 30 SECONDS
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> >>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> >>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> >>>>>> at
> >> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> >>>>>> at
> >> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> >>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> >>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> >>>>>> at
> >>>>>
> >>>
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> >>>>>> at
> >>>>>
> >>>
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> >>>>>> at
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> >>>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> >>>>>> at
> >>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> >>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> >>>>>> at
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> >>>>>> at
> >> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>>>> at
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>> *
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -------------------------------------------------------------------
> >>>> *SCJA. José Luis Cetina*
> >>>> -------------------------------------------------------------------
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Jean-Louis
> >>>
> >>
> >>
> >>
> >> --
> >> -------------------------------------------------------------------
> >> *SCJA. José Luis Cetina*
> >> -------------------------------------------------------------------
> >>
>
>
Re: ConcurrentAccessTimeoutException
Posted by David Blevins <da...@gmail.com>.
I'd also recommend @Singleton in conjunction with @Lock(READ).
The @Stateless bean type is good when you explicitly need to limit the number of instances/concurrent calls. If this sort of limiting is not a critical part of the design, then likely @Stateless was used because this is the bean type people tend to use by default.
Really, @Singleton with @Lock(READ) should be used by default and other bean types used only when there is a specific design goal you need to achieve.
-David
On Mar 6, 2013, at 10:19 AM, Romain Manni-Bucau <rm...@gmail.com> wrote:
> In very very heavy load and for a simple app it can be as much as your http
> request thread pool size (200 by default)
>
> Note: using @Singleton can help too if you can
> Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a écrit :
>
>> Really im not sure how many users the webapp could handle, because is a
>> public webapp, i will increase the MaxSize to 50 or 100, but for any
>> "unexpected
>> overload" i will let StrictPooling to false.
>>
>> Do you consider its to much to increase to 50/100 to maxsize??
>>
>>
>>
>> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
>>
>>> José,
>>>
>>> The MinSize is not the problem IMO.
>>> The MaxSize is definitely the issue. Do you have more than 10 (default
>>> value) simultaneous users?
>>>
>>> The StrictPooling is great to be able to always answer in case of small
>>> over load.
>>> But, you have to know that after being used, instances will be removed
>> and
>>> garbage collected.
>>>
>>> Also, creating instances can be consuming depending on the bean.
>>>
>>> I would recommend not only to set it to true, but before, trying to
>> define
>>> as much as possible the correct value for MaxSize depending on your SLAs.
>>>
>>> Hope it helps
>>> JLouis
>>>
>>>
>>>
>>>
>>> 2013/3/6 José Luis Cetina <ma...@gmail.com>
>>>
>>>> Im using 1.6.0-SNAPSHOT.
>>>>
>>>> I will change
>>>>
>>>> StrictPooling = true ==> false
>>>> MinSize = 0 ==> 2
>>>>
>>>> In stateless section and let you know.
>>>>
>>>>
>>>>
>>>> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
>>>>
>>>>> José,
>>>>>
>>>>> I'm sure the others will ask, are you seeing this with tomee 1.5.2 or
>>>> 1.6.0
>>>>> snapshot? or only seeing on your production server running tomee
>> 1.5.1
>>>> or
>>>>> 1.5.2 / 1.6.0 snapshot?
>>>>>
>>>>> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
>>>>>
>>>>> Also, i searched google for the following:
>>>>>
>>>>> No instances available in Stateless Session Bean pool
>>>>>
>>>>> and found the following (which is definitely related to Jean-Louis
>>>>> response):
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>
>>>
>> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
>>>>>
>>>>> [2]
>>>>>
>>>>>
>>>>
>>>
>> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
>>>>>
>>>>> [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
>>>>>
>>>>>
>>>>> Howard
>>>>>
>>>>>
>>>>> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
>>> maxtorzito@gmail.com
>>>>>> wrote:
>>>>>
>>>>>> Hi im gettin *ConcurrentAccessTimeoutException: No instances
>>> available
>>>> in
>>>>>> Stateless Session Bean pool. Waited 30 SECONDS....*
>>>>>>
>>>>>> Here is the complete log: http://pastebin.ca/2328770
>>>>>>
>>>>>> Any advice, what could be? Do i have to configure something in
>>>>> tomee.xml??
>>>>>>
>>>>>> Part of the log:
>>>>>>
>>>>>>
>>>>>> *Mar 05, 2013 9:38:20 PM
>> org.apache.openejb.cdi.CdiAppContextsService
>>>>>> lazyStartSessionContext
>>>>>> WARNING: Could NOT lazily initialize session context because of
>> null
>>>>>> RequestContext
>>>>>> javax.ejb.ConcurrentAccessTimeoutException: No instances available
>> in
>>>>>> Stateless Session Bean pool. Waited 30 SECONDS
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
>>>>>> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
>>>>>> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>>>> at java.lang.reflect.Method.invoke(Method.java:601)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
>>>>>> at
>> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
>>>>>> at
>> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
>>>>>> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
>>>>>> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
>>>>>> at
>>>>>
>>> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
>>>>>> at
>>>>>
>>> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
>>>>>> at
>>>>>>
>>>>>
>>>>
>>>
>> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
>>>>>> at
>>>>>>
>>>>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
>>>>>> at
>>>>>>
>>>>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
>>>>>> at
>>>>>>
>>>>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
>>>>>> at
>>>>>>
>>>>
>> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
>>>>>> at
>>>>>>
>>>>
>> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
>>>>>> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>>>>>> at
>>> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
>>>>>> at
>>>>>>
>>>>
>> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>>>>>> at
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
>>>>>> at
>> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>> at
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>> *
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -------------------------------------------------------------------
>>>> *SCJA. José Luis Cetina*
>>>> -------------------------------------------------------------------
>>>>
>>>
>>>
>>>
>>> --
>>> Jean-Louis
>>>
>>
>>
>>
>> --
>> -------------------------------------------------------------------
>> *SCJA. José Luis Cetina*
>> -------------------------------------------------------------------
>>
Re: ConcurrentAccessTimeoutException
Posted by Romain Manni-Bucau <rm...@gmail.com>.
In very very heavy load and for a simple app it can be as much as your http
request thread pool size (200 by default)
Note: using @Singleton can help too if you can
Le 6 mars 2013 18:51, "José Luis Cetina" <ma...@gmail.com> a écrit :
> Really im not sure how many users the webapp could handle, because is a
> public webapp, i will increase the MaxSize to 50 or 100, but for any
> "unexpected
> overload" i will let StrictPooling to false.
>
> Do you consider its to much to increase to 50/100 to maxsize??
>
>
>
> 2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
>
> > José,
> >
> > The MinSize is not the problem IMO.
> > The MaxSize is definitely the issue. Do you have more than 10 (default
> > value) simultaneous users?
> >
> > The StrictPooling is great to be able to always answer in case of small
> > over load.
> > But, you have to know that after being used, instances will be removed
> and
> > garbage collected.
> >
> > Also, creating instances can be consuming depending on the bean.
> >
> > I would recommend not only to set it to true, but before, trying to
> define
> > as much as possible the correct value for MaxSize depending on your SLAs.
> >
> > Hope it helps
> > JLouis
> >
> >
> >
> >
> > 2013/3/6 José Luis Cetina <ma...@gmail.com>
> >
> > > Im using 1.6.0-SNAPSHOT.
> > >
> > > I will change
> > >
> > > StrictPooling = true ==> false
> > > MinSize = 0 ==> 2
> > >
> > > In stateless section and let you know.
> > >
> > >
> > >
> > > 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> > >
> > > > José,
> > > >
> > > > I'm sure the others will ask, are you seeing this with tomee 1.5.2 or
> > > 1.6.0
> > > > snapshot? or only seeing on your production server running tomee
> 1.5.1
> > > or
> > > > 1.5.2 / 1.6.0 snapshot?
> > > >
> > > > Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> > > >
> > > > Also, i searched google for the following:
> > > >
> > > > No instances available in Stateless Session Bean pool
> > > >
> > > > and found the following (which is definitely related to Jean-Louis
> > > > response):
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> > > >
> > > > [2]
> > > >
> > > >
> > >
> >
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> > > >
> > > > [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> > > >
> > > >
> > > > Howard
> > > >
> > > >
> > > > On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> > maxtorzito@gmail.com
> > > > >wrote:
> > > >
> > > > > Hi im gettin *ConcurrentAccessTimeoutException: No instances
> > available
> > > in
> > > > > Stateless Session Bean pool. Waited 30 SECONDS....*
> > > > >
> > > > > Here is the complete log: http://pastebin.ca/2328770
> > > > >
> > > > > Any advice, what could be? Do i have to configure something in
> > > > tomee.xml??
> > > > >
> > > > > Part of the log:
> > > > >
> > > > >
> > > > > *Mar 05, 2013 9:38:20 PM
> org.apache.openejb.cdi.CdiAppContextsService
> > > > > lazyStartSessionContext
> > > > > WARNING: Could NOT lazily initialize session context because of
> null
> > > > > RequestContext
> > > > > javax.ejb.ConcurrentAccessTimeoutException: No instances available
> in
> > > > > Stateless Session Bean pool. Waited 30 SECONDS
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> > > > > at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> > > > > at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > > at java.lang.reflect.Method.invoke(Method.java:601)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> > > > > at
> javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> > > > > at
> org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> > > > > at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> > > > > at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> > > > > at
> > > >
> > org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> > > > > at
> > > >
> > javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> > > > > at
> > > > >
> > > >
> > >
> >
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> > > > > at
> > > > >
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> > > > > at
> > > > >
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > > > at
> > > > >
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > > > at
> > > > >
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> > > > > at
> > > > >
> > >
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> > > > > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> > > > > at
> > org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> > > > > at
> > > > >
> > >
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> > > > > at
> > > > >
> > > >
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> > > > > at
> org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > > > > at
> > > > >
> > > > >
> > > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > > > > at java.lang.Thread.run(Thread.java:722)
> > > > > *
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > -------------------------------------------------------------------
> > > *SCJA. José Luis Cetina*
> > > -------------------------------------------------------------------
> > >
> >
> >
> >
> > --
> > Jean-Louis
> >
>
>
>
> --
> -------------------------------------------------------------------
> *SCJA. José Luis Cetina*
> -------------------------------------------------------------------
>
Re: ConcurrentAccessTimeoutException
Posted by José Luis Cetina <ma...@gmail.com>.
Really im not sure how many users the webapp could handle, because is a
public webapp, i will increase the MaxSize to 50 or 100, but for any
"unexpected
overload" i will let StrictPooling to false.
Do you consider its to much to increase to 50/100 to maxsize??
2013/3/6 Jean-Louis MONTEIRO <je...@gmail.com>
> José,
>
> The MinSize is not the problem IMO.
> The MaxSize is definitely the issue. Do you have more than 10 (default
> value) simultaneous users?
>
> The StrictPooling is great to be able to always answer in case of small
> over load.
> But, you have to know that after being used, instances will be removed and
> garbage collected.
>
> Also, creating instances can be consuming depending on the bean.
>
> I would recommend not only to set it to true, but before, trying to define
> as much as possible the correct value for MaxSize depending on your SLAs.
>
> Hope it helps
> JLouis
>
>
>
>
> 2013/3/6 José Luis Cetina <ma...@gmail.com>
>
> > Im using 1.6.0-SNAPSHOT.
> >
> > I will change
> >
> > StrictPooling = true ==> false
> > MinSize = 0 ==> 2
> >
> > In stateless section and let you know.
> >
> >
> >
> > 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> >
> > > José,
> > >
> > > I'm sure the others will ask, are you seeing this with tomee 1.5.2 or
> > 1.6.0
> > > snapshot? or only seeing on your production server running tomee 1.5.1
> > or
> > > 1.5.2 / 1.6.0 snapshot?
> > >
> > > Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> > >
> > > Also, i searched google for the following:
> > >
> > > No instances available in Stateless Session Bean pool
> > >
> > > and found the following (which is definitely related to Jean-Louis
> > > response):
> > >
> > > [1]
> > >
> > >
> >
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> > >
> > > [2]
> > >
> > >
> >
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> > >
> > > [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> > >
> > >
> > > Howard
> > >
> > >
> > > On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <
> maxtorzito@gmail.com
> > > >wrote:
> > >
> > > > Hi im gettin *ConcurrentAccessTimeoutException: No instances
> available
> > in
> > > > Stateless Session Bean pool. Waited 30 SECONDS....*
> > > >
> > > > Here is the complete log: http://pastebin.ca/2328770
> > > >
> > > > Any advice, what could be? Do i have to configure something in
> > > tomee.xml??
> > > >
> > > > Part of the log:
> > > >
> > > >
> > > > *Mar 05, 2013 9:38:20 PM org.apache.openejb.cdi.CdiAppContextsService
> > > > lazyStartSessionContext
> > > > WARNING: Could NOT lazily initialize session context because of null
> > > > RequestContext
> > > > javax.ejb.ConcurrentAccessTimeoutException: No instances available in
> > > > Stateless Session Bean pool. Waited 30 SECONDS
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> > > > at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> > > > at
> > > >
> > > >
> > >
> >
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> > > > at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> > > > at
> > > >
> > > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > > at java.lang.reflect.Method.invoke(Method.java:601)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> > > > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> > > > at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> > > > at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> > > > at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> > > > at
> > >
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> > > > at
> > >
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> > > > at
> > > >
> > >
> >
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> > > > at
> > > >
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> > > > at
> > > >
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > > at
> > > >
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > > at
> > > >
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> > > > at
> > > >
> > > >
> > >
> >
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> > > > at
> > > >
> > org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> > > > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> > > > at
> org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> > > > at
> > > >
> > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> > > > at
> > > >
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> > > > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> > > > at
> > > >
> > > >
> > >
> >
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> > > > at
> > > >
> > > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > > > at
> > > >
> > > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > > > at java.lang.Thread.run(Thread.java:722)
> > > > *
> > > >
> > >
> >
> >
> >
> > --
> > -------------------------------------------------------------------
> > *SCJA. José Luis Cetina*
> > -------------------------------------------------------------------
> >
>
>
>
> --
> Jean-Louis
>
--
-------------------------------------------------------------------
*SCJA. José Luis Cetina*
-------------------------------------------------------------------
Re: ConcurrentAccessTimeoutException
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
José,
The MinSize is not the problem IMO.
The MaxSize is definitely the issue. Do you have more than 10 (default
value) simultaneous users?
The StrictPooling is great to be able to always answer in case of small
over load.
But, you have to know that after being used, instances will be removed and
garbage collected.
Also, creating instances can be consuming depending on the bean.
I would recommend not only to set it to true, but before, trying to define
as much as possible the correct value for MaxSize depending on your SLAs.
Hope it helps
JLouis
2013/3/6 José Luis Cetina <ma...@gmail.com>
> Im using 1.6.0-SNAPSHOT.
>
> I will change
>
> StrictPooling = true ==> false
> MinSize = 0 ==> 2
>
> In stateless section and let you know.
>
>
>
> 2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
>
> > José,
> >
> > I'm sure the others will ask, are you seeing this with tomee 1.5.2 or
> 1.6.0
> > snapshot? or only seeing on your production server running tomee 1.5.1
> or
> > 1.5.2 / 1.6.0 snapshot?
> >
> > Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
> >
> > Also, i searched google for the following:
> >
> > No instances available in Stateless Session Bean pool
> >
> > and found the following (which is definitely related to Jean-Louis
> > response):
> >
> > [1]
> >
> >
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
> >
> > [2]
> >
> >
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
> >
> > [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
> >
> >
> > Howard
> >
> >
> > On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <maxtorzito@gmail.com
> > >wrote:
> >
> > > Hi im gettin *ConcurrentAccessTimeoutException: No instances available
> in
> > > Stateless Session Bean pool. Waited 30 SECONDS....*
> > >
> > > Here is the complete log: http://pastebin.ca/2328770
> > >
> > > Any advice, what could be? Do i have to configure something in
> > tomee.xml??
> > >
> > > Part of the log:
> > >
> > >
> > > *Mar 05, 2013 9:38:20 PM org.apache.openejb.cdi.CdiAppContextsService
> > > lazyStartSessionContext
> > > WARNING: Could NOT lazily initialize session context because of null
> > > RequestContext
> > > javax.ejb.ConcurrentAccessTimeoutException: No instances available in
> > > Stateless Session Bean pool. Waited 30 SECONDS
> > > at
> > >
> > >
> >
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> > > at
> > >
> > >
> >
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> > > at
> > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> > > at
> > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> > > at
> > >
> > >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> > > at
> > >
> > >
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> > > at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> > > at
> > >
> > >
> >
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> > > at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> > > at
> > >
> > >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > > at java.lang.reflect.Method.invoke(Method.java:601)
> > > at
> > >
> > >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> > > at
> > >
> > >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> > > at
> > >
> > >
> >
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> > > at
> > >
> > >
> >
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> > > at
> > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> > > at
> > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> > > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> > > at
> > >
> > >
> >
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> > > at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> > > at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> > > at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> > > at
> > org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> > > at
> > >
> > >
> >
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> > > at
> > >
> > >
> >
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> > > at
> > javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> > > at
> > >
> >
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> > > at
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> > > at
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > at
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > at
> > >
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > > at
> > >
> > >
> >
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> > > at
> > >
> > >
> >
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> > > at
> > >
> > >
> >
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> > > at
> > >
> > >
> >
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> > > at
> > >
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> > > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> > > at
> > >
> > >
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> > > at
> > >
> > >
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> > > at
> > >
> > >
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> > > at
> > >
> > >
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> > > at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> > > at
> > >
> > >
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> > > at
> > >
> > >
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> > > at
> > >
> > >
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> > > at
> > >
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> > > at
> > >
> > >
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> > > at
> > >
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> > > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> > > at
> > >
> > >
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> > > at
> > >
> > >
> >
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> > > at
> > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > > at
> > >
> > >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > > at java.lang.Thread.run(Thread.java:722)
> > > *
> > >
> >
>
>
>
> --
> -------------------------------------------------------------------
> *SCJA. José Luis Cetina*
> -------------------------------------------------------------------
>
--
Jean-Louis
Re: ConcurrentAccessTimeoutException
Posted by José Luis Cetina <ma...@gmail.com>.
Im using 1.6.0-SNAPSHOT.
I will change
StrictPooling = true ==> false
MinSize = 0 ==> 2
In stateless section and let you know.
2013/3/6 Howard W. Smith, Jr. <sm...@gmail.com>
> José,
>
> I'm sure the others will ask, are you seeing this with tomee 1.5.2 or 1.6.0
> snapshot? or only seeing on your production server running tomee 1.5.1 or
> 1.5.2 / 1.6.0 snapshot?
>
> Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
>
> Also, i searched google for the following:
>
> No instances available in Stateless Session Bean pool
>
> and found the following (which is definitely related to Jean-Louis
> response):
>
> [1]
>
> http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
>
> [2]
>
> http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
>
> [3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
>
>
> Howard
>
>
> On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <maxtorzito@gmail.com
> >wrote:
>
> > Hi im gettin *ConcurrentAccessTimeoutException: No instances available in
> > Stateless Session Bean pool. Waited 30 SECONDS....*
> >
> > Here is the complete log: http://pastebin.ca/2328770
> >
> > Any advice, what could be? Do i have to configure something in
> tomee.xml??
> >
> > Part of the log:
> >
> >
> > *Mar 05, 2013 9:38:20 PM org.apache.openejb.cdi.CdiAppContextsService
> > lazyStartSessionContext
> > WARNING: Could NOT lazily initialize session context because of null
> > RequestContext
> > javax.ejb.ConcurrentAccessTimeoutException: No instances available in
> > Stateless Session Bean pool. Waited 30 SECONDS
> > at
> >
> >
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> > at
> >
> >
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> > at
> >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> > at
> >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> > at
> >
> >
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> > at
> >
> >
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> > at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> > at
> >
> >
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> > at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> > at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:601)
> > at
> >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> > at
> >
> >
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> > at
> >
> >
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> > at
> >
> >
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> > at
> >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> > at
> >
> >
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> > at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> > at
> >
> >
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> > at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> > at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> > at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> > at
> org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> > at
> >
> >
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> > at
> >
> >
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> > at
> javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> > at
> >
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> > at
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> > at
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > at
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > at
> > javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> > at
> >
> >
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> > at
> >
> >
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> > at
> >
> >
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> > at
> >
> >
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> > at
> > org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> > at
> >
> >
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> > at
> >
> >
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> > at
> >
> >
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> > at
> >
> >
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> > at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> > at
> >
> >
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> > at
> >
> >
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> > at
> >
> >
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> > at
> > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> > at
> >
> >
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> > at
> >
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> > at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> > at
> >
> >
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> > at
> >
> >
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:722)
> > *
> >
>
--
-------------------------------------------------------------------
*SCJA. José Luis Cetina*
-------------------------------------------------------------------
Re: ConcurrentAccessTimeoutException
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
José,
I'm sure the others will ask, are you seeing this with tomee 1.5.2 or 1.6.0
snapshot? or only seeing on your production server running tomee 1.5.1 or
1.5.2 / 1.6.0 snapshot?
Wow, Jean-Louis beat me to it...asking for the TOMEE version. :)
Also, i searched google for the following:
No instances available in Stateless Session Bean pool
and found the following (which is definitely related to Jean-Louis
response):
[1]
http://apache-geronimo.328035.n3.nabble.com/jira-Created-GERONIMO-5455-quot-No-instances-available-in-Stateless-Session-Bean-pool-quot-error-wher-td978236.html
[2]
http://openejb.979440.n4.nabble.com/Query-Regarding-Stateless-Session-Bean-Instance-Pool-Configuration-td980239.html
[3] http://docs.oracle.com/cd/E15051_01/wls/docs103/ejb/session.html
Howard
On Wed, Mar 6, 2013 at 10:46 AM, José Luis Cetina <ma...@gmail.com>wrote:
> Hi im gettin *ConcurrentAccessTimeoutException: No instances available in
> Stateless Session Bean pool. Waited 30 SECONDS....*
>
> Here is the complete log: http://pastebin.ca/2328770
>
> Any advice, what could be? Do i have to configure something in tomee.xml??
>
> Part of the log:
>
>
> *Mar 05, 2013 9:38:20 PM org.apache.openejb.cdi.CdiAppContextsService
> lazyStartSessionContext
> WARNING: Could NOT lazily initialize session context because of null
> RequestContext
> javax.ejb.ConcurrentAccessTimeoutException: No instances available in
> Stateless Session Bean pool. Waited 30 SECONDS
> at
>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> at
>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> at
>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> at
>
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
>
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> at
>
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> at
>
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> at
>
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> at
>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> at
>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> at
>
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> at
>
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> at
>
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> at javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> at
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> at
>
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> at
>
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> at
>
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> at
>
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> at
>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> at
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> at
>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> at
>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> *
>
Re: ConcurrentAccessTimeoutException
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
TomEE version would be helpful for us.
Anyway no changes on that area as far as I recall.
It means, that you are trying to stress the server with more than the
available instances in the pool.
FYI, here is the default configuration of the stateless container. You can
override it depending on your application and the number of simultaneous
virtual users.
<!--
# ==========================================================
# Default Stateless SessionBean Container
# ==========================================================
-->
<ServiceProvider
id="Default Stateless Container"
service="Container"
types="STATELESS"
factory-name="create"
class-name="org.apache.openejb.core.stateless.StatelessContainerFactory">
# Specifies the time an invokation should wait for an instance
# of the pool to become available.
#
# After the timeout is reached, if an instance in the pool cannot
# be obtained, the method invocation will fail.
#
# Usable time units: nanoseconds, microsecons, milliseconds,
# seconds, minutes, hours, days. Or any combination such as
# "1 hour and 27 minutes and 10 seconds"
#
# Any usage of the `javax.ejb.AccessTimeout` annotation will
# override this setting for the bean or method where the
# annotation is used.
AccessTimeout = 30 seconds
# Specifies the size of the bean pools for this stateless
# SessionBean container. If StrictPooling is not used, instances
# will still be created beyond this number if there is demand, but
# they will not be returned to the pool and instead will be
# immediately destroyed.
MaxSize = 10
# Specifies the minimum number of bean instances that should be in
# the pool for each bean. Pools are prefilled to the minimum on
# startup. Note this will create start order dependencies between
# other beans that also eagerly start, such as other `@Stateless`
# beans with a minimum or `@Singleton` beans using `@Startup`. The
# @DependsOn annotation can be used to appropriately influence
# start order.
#
# The minimum pool size is rigidly maintained. Instances in the
# minimum side of the pool are not eligible for `IdleTimeout` or
# `GarbageCollection`, but are subject to `MaxAge` and flushing.
#
# If the pool is flushed it is immediately refilled to the minimum
# size with `MaxAgeOffset` applied. If an instance from the minimum
# side of the pool reaches its `MaxAge`, it is also immediately
# replaced. Replacement is done in a background queue using the
# number of threads specified by `CallbackThreads`.
MinSize = 0
# StrictPooling tells the container what to do when the pool
# reaches it's maximum size and there are incoming requests that
# need instances.
#
# With strict pooling, requests will have to wait for instances to
# become available. The pool size will never grow beyond the the
# set `MaxSize` value. The maximum amount of time a request should
# wait is specified via the `AccessTimeout` setting.
#
# Without strict pooling, the container will create temporary
# instances to meet demand. The instances will last for just one
# method invocation and then are removed.
#
# Setting `StrictPooling` to `false` and `MaxSize` to `0` will result in
# no pooling. Instead instances will be created on demand and live
# for exactly one method call before being removed.
StrictPooling = true
# Specifies the maximum time that an instance should live before
# it should be retired and removed from use. This will happen
# gracefully. Useful for situations where bean instances are
# designed to hold potentially expensive resources such as memory
# or file handles and need to be periodically cleared out.
#
# Usable time units: nanoseconds, microsecons, milliseconds,
# seconds, minutes, hours, days. Or any combination such as
# `1 hour and 27 minutes and 10 seconds`
MaxAge = 0 hours
# When `ReplaceAged` is enabled, any instances in the pool that
# expire due to reaching their `MaxAge` will be replaced immediately
# so that the pool will remain at its current size. Replacement
# is done in a background queue so that incoming threads will not
# have to wait for instance creation.
#
# The aim of his option is to prevent user requests from paying
# the instance creation cost as `MaxAge` is enforced, potentially
# while under heavy load at peak hours.
#
# Instances from the minimum side of the pool are always replaced
# when they reach their `MaxAge`, this setting dictates the
# treatment of non-minimum instances.
ReplaceAged = true
# When `ReplaceFlushed` is enabled, any instances in the pool that
# are flushed will be replaced immediately so that the pool will
# remain at its current size. Replacement is done in a background
# queue so that incoming threads will not have to wait for
# instance creation.
#
# The aim of his option is to prevent user requests from paying
# the instance creation cost if a flush performed while under
# heavy load at peak hours.
#
# Instances from the minimum side of the pool are always replaced
# when they are flushed, this setting dictates the treatment of
# non-minimum instances.
#
# A bean may flush its pool by casting the `SessionContext` to
# `Flushable` and calling `flush()`. See `SweepInterval` for details on
# how flush is performed.
#
# import javax.annotation.Resource;
# import javax.ejb.SessionContext;
# import javax.ejb.Stateless;
# import java.io.Flushable;
# import java.io.IOException;
#
# @Stateless
# public class MyBean {
#
# @Resource
# private SessionContext sessionContext;
#
# public void flush() throws IOException {
#
# ((Flushable) sessionContext).flush();
# }
# }
ReplaceFlushed = false
# Applies to MaxAge usage and would rarely be changed, but is a
# nice feature to understand.
#
# When the container first starts and the pool is filled to the
# minimum size, all those "minimum" instances will have the same
# creation time and therefore all expire at the same time dictated
# by the `MaxAge` setting. To protect against this sudden drop
# scenario and provide a more gradual expiration from the start
# the container will spread out the age of the instances that fill
# the pool to the minimum using an offset.
#
# The `MaxAgeOffset` is not the final value of the offset, but
# rather it is used in creating the offset and allows the
# spreading to push the initial ages into the future or into the
# past. The pool is filled at startup as follows:
#
# for (int i = 0; i < poolMin; i++) {
# long ageOffset = (maxAge / poolMin * i * maxAgeOffset) % maxAge;
# pool.add(new Bean(), ageOffset));
# }
#
# The default `MaxAgeOffset` is -1 which causes the initial
# instances in the pool to live a bit longer before expiring. As
# a concrete example, let's say the MinSize is 4 and the MaxAge is
# 100 years. The generated offsets for the four instances created
# at startup would be 0, -25, -50, -75. So the first instance
# would be "born" at age 0, die at 100, living 100 years. The
# second instance would be born at -25, die at 100, living a total
# of 125 years. The third would live 150 years. The fourth 175
# years.
#
# A `MaxAgeOffset` of 1 would cause instances to be "born" older
# and therefore die sooner. Using the same example `MinSize` of 4
# and `MaxAge` of `100 years`, the life spans of these initial four
# instances would be 100, 75, 50, and 25 years respectively.
#
# A `MaxAgeOffset` of 0 will cause no "spreading" of the age of the
# first instances used to fill the pool to the minimum and these
# instances will of course reach their MaxAge at the same time.
# It is possible to set to decimal values such as -0.5, 0.5, -1.2,
# or 1.2.
MaxAgeOffset = -1
# Specifies the maximum time that an instance should be allowed to
# sit idly in the pool without use before it should be retired and
# removed.
#
# Usable time units: nanoseconds, microsecons, milliseconds,
# seconds, minutes, hours, days. Or any combination such as
# "1 hour and 27 minutes and 10 seconds"
IdleTimeout = 0 minutes
# Allows Garbage Collection to be used as a mechanism for shrinking
# the pool. When set to true all instances in the pool, excluding
# the minimum, are eligible for garbage collection by the virtual
# machine as per the rules of `java.lang.ref.SoftReference` and can be
# claimed by the JVM to free memory. Instances garbage collected
# will have their `@PreDestroy` methods called during finalization.
#
# In the OpenJDK VM the `-XX:SoftRefLRUPolicyMSPerMB` flag can adjust
# how aggressively SoftReferences are collected. The default
# OpenJDK setting is 1000, resulting in inactive pooled instances
# living one second of lifetime per free megabyte in the heap, which
# is very aggressive. The setting should be increased to get the
# most out of the `GarbageCollection` feature of the pool. Much
# higher settings are safe. Even a setting as high as 3600000 (1
# hour per free MB in the heap) does not affect the ability for the
# VM to garbage collect SoftReferences in the event that memory is
# needed to avoid an `OutOfMemoryException`.
GarbageCollection = false
# The frequency in which the container will sweep the pool and
# evict expired instances. Eviction is how the `IdleTimeout`,
# `MaxAge`, and pool "flush" functionality is enforced. Higher
# intervals are better.
#
# Instances in use are excluded from sweeping. Should an instance
# expire while in use it will be evicted immediately upon return
# to the pool. Effectively `MaxAge` and flushes will be enforced as
# a part of normal activity or sweeping, while IdleTimeout is only
# enforcable via sweeping. This makes aggressive sweeping less
# important for a pool under moderate load.
#
# Usable time units: nanoseconds, microsecons, milliseconds,
# seconds, minutes, hours, days. Or any combination such as
# `1 hour and 27 minutes and 10 seconds`
SweepInterval = 5 minutes
# When sweeping the pool for expired instances a thread pool is
# used to process calling `@PreDestroy` on expired instances as well
# as creating new instances as might be required to fill the pool
# to the minimum after a Flush or `MaxAge` expiration. The
# `CallbackThreads` setting dictates the size of the thread pool and
# is shared by all beans deployed in the container.
CallbackThreads = 5
# PostConstruct methods are invoked on all instances in the pool
# when the bean is undeployed and its pool is closed. The
# `CloseTimeout` specifies the maximum time to wait for the pool to
# close and `PostConstruct` methods to be invoked.
#
# Usable time units: nanoseconds, microsecons, milliseconds,
# seconds, minutes, hours, days. Or any combination such as
# `1 hour and 27 minutes and 10 seconds`
CloseTimeout = 5 minutes
</ServiceProvider>
JLouis
2013/3/6 José Luis Cetina <ma...@gmail.com>
> Hi im gettin *ConcurrentAccessTimeoutException: No instances available in
> Stateless Session Bean pool. Waited 30 SECONDS....*
>
> Here is the complete log: http://pastebin.ca/2328770
>
> Any advice, what could be? Do i have to configure something in tomee.xml??
>
> Part of the log:
>
>
> *Mar 05, 2013 9:38:20 PM org.apache.openejb.cdi.CdiAppContextsService
> lazyStartSessionContext
> WARNING: Could NOT lazily initialize session context because of null
> RequestContext
> javax.ejb.ConcurrentAccessTimeoutException: No instances available in
> Stateless Session Bean pool. Waited 30 SECONDS
> at
>
> org.apache.openejb.core.stateless.StatelessInstanceManager.getInstance(StatelessInstanceManager.java:190)
> at
>
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:186)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.synchronizedBusinessMethod(EjbObjectProxyHandler.java:256)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:251)
> at
>
> org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:85)
> at
>
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:279)
> at sun.proxy.$Proxy245.getExamenAplicado(Unknown Source)
> at
>
> com.grupokx.preparatorianos.controller.examendiagnostico.ExamenDiagnosticoMBean.mypostconstruct(ExamenDiagnosticoMBean.java:63)
> at sun.reflect.GeneratedMethodAccessor800.invoke(Unknown Source)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at
>
> org.apache.tomee.catalina.JavaeeInstanceManager.postConstruct(JavaeeInstanceManager.java:132)
> at
>
> org.apache.tomee.catalina.JavaeeInstanceManager.newInstance(JavaeeInstanceManager.java:69)
> at
>
> org.apache.myfaces.config.annotation.Tomcat7AnnotationLifecycleProvider.postConstruct(Tomcat7AnnotationLifecycleProvider.java:94)
> at
>
> org.apache.myfaces.config.ManagedBeanBuilder.buildManagedBean(ManagedBeanBuilder.java:213)
> at
>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.createManagedBean(ManagedBeanResolver.java:333)
> at
>
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver.getValue(ManagedBeanResolver.java:296)
> at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:58)
> at
>
> org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:179)
> at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:72)
> at org.apache.el.parser.AstValue.getValue(AstValue.java:161)
> at org.apache.el.parser.AstEqual.getValue(AstEqual.java:38)
> at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185)
> at
>
> org.apache.webbeans.el.WrappedValueExpression.getValue(WrappedValueExpression.java:68)
> at
>
> org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
> at javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:266)
> at
> javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1187)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:494)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> at
> javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541)
> at
>
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1981)
> at
>
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
> at
>
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
> at
>
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
> at
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> at
>
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
>
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
>
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:45)
> at
>
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> at
>
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
>
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> at
>
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:200)
> at
>
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> at
>
> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> at
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> *
>
--
Jean-Louis