saw it ;-) thanks!
On Fri, Apr 10, 2009 at 11:12 AM, Matthias Wessendorf <[email protected]> wrote: > can you update the jira ticket with that information ? > > On Fri, Apr 10, 2009 at 10:42 AM, Rupak Kumar Sah > <[email protected]> wrote: >> I removed the <trh:script> tag that imports the js, and the js reference >> from the jsp, and found the same issue that is the thread again gets blocked. >> This means the issue is not with <trh:script> tag as we suspected earlier, >> but it is somewhere else. >> >> Here are the logs: >> >> <Apr 10, 2009 1:43:49 PM IST> <Error> <WebLogicServer> <BEA-000337> <[STUCK] >> ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)' has >> been busy for "648" seconds working on the request "Http Request: >> /Advisor/faces/iAdvisorWeb/bundles/profilemanager/jsf/usersandgroups/createnewuser.jspx", >> which is more than the configured time (StuckThreadMaxTime) of "600" >> seconds. Stack trace: >> java.lang.Object.wait(Native Method) >> weblogic.rjvm.ResponseImpl.waitForData(ResponseImpl.java:73) >> weblogic.rjvm.ResponseImpl.getTxContext(ResponseImpl.java:100) >> >> weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:109) >> weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:223) >> >> weblogic.cluster.replication.ReplicationManager_920_WLStub.create(Unknown >> Source) >> >> weblogic.cluster.replication.ReplicationManager.trySecondary(ReplicationManager.java:658) >> >> weblogic.cluster.replication.ReplicationManager.createSecondary(ReplicationManager.java:630) >> >> weblogic.cluster.replication.ReplicationManager.updateSecondary(ReplicationManager.java:556) >> >> weblogic.servlet.internal.session.ReplicatedSessionData.syncSession(ReplicatedSessionData.java:516) >> >> weblogic.servlet.internal.session.ReplicatedSessionContext.sync(ReplicatedSessionContext.java:82) >> >> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.syncSession(ServletRequestImpl.java:2485) >> >> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.syncSession(ServletRequestImpl.java:2460) >> >> weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1279) >> >> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1353) >> weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) >> weblogic.work.ExecuteThread.run(ExecuteThread.java:181) >>> >> <Apr 10, 2009 1:43:49 PM IST> <Error> <WebLogicServer> <BEA-000337> <[STUCK] >> ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)' has >> been busy for "608" seconds working on the request "Http Request: >> /Advisor/iAdvisorWeb/bundles/ic/skins/FND/images/cafebad.gif", which is more >> than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace: >> >> weblogic.servlet.internal.session.ReplicatedSessionContext.getSessionInternal(ReplicatedSessionContext.java:375) >> >> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.getValidSession(ServletRequestImpl.java:2521) >> >> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.getSessionInternal(ServletRequestImpl.java:2090) >> >> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.getSession(ServletRequestImpl.java:2057) >> >> weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1189) >> >> weblogic.servlet.security.internal.SecurityModule$SessionRetrievalAction.run(SecurityModule.java:535) >> >> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) >> >> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) >> >> weblogic.servlet.security.internal.SecurityModule.getUserSession(SecurityModule.java:426) >> >> weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(ServletSecurityManager.java:81) >> >> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:1920) >> >> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:1890) >> >> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1344) >> weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) >> weblogic.work.ExecuteThread.run(ExecuteThread.java:181) >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of >> Matthias Wessendorf >> Sent: Wednesday, April 08, 2009 7:52 PM >> To: MyFaces Development >> Cc: Sabitha Gopal Pandit >> Subject: Re: <trh:script> tag causes deadlock on weblogic 9.2 cluster >> >> Sabitha, >> >> can you take a look at the bug ? >> Max Starets added a comment. >> >> Thx, >> Matthias >> >> On Wed, Apr 8, 2009 at 2:42 PM, Sabitha Gopal Pandit >> <[email protected]> wrote: >>> I have raised TRINIDAD-1450 for this issue >>> >>> Thanks, >>> Sabitha >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Matthias Wessendorf >>> Sent: Wednesday, April 08, 2009 6:08 PM >>> To: MyFaces Development >>> Subject: Re: <trh:script> tag causes deadlock on weblogic 9.2 cluster >>> >>> On Wed, Apr 8, 2009 at 2:33 PM, Sabitha Gopal Pandit >>> <[email protected]> wrote: >>>> Can I know the URL to create the JIRA? >>> >>> https://issues.apache.org/jira/browse/TRINIDAD >>> >>> -M >>> >>>> >>>> Thanks, >>>> Sabitha >>>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>> Matthias Wessendorf >>>> Sent: Wednesday, April 08, 2009 6:02 PM >>>> To: MyFaces Development >>>> Subject: Re: <trh:script> tag causes deadlock on weblogic 9.2 cluster >>>> >>>> Hey Sabitha, >>>> >>>> can you create a JIRA ticket ? >>>> Once done, I'll ask our WLS folks to take a look... >>>> >>>> thanks, >>>> matthias >>>> >>>> On Wed, Apr 8, 2009 at 2:23 PM, Sabitha Gopal Pandit >>>> <[email protected]> wrote: >>>>> Hi Matthias, >>>>> >>>>> As part facelets1.1.14 the el jars which earlier was el-ri.jar is now >>>>> el-impl.jar >>>>> >>>>> We have identified that any JSF page with the <trh:script> which is used >>>>> to load javascripts is causing this. >>>>> >>>>> Simple JSF page works. >>>>> >>>>> Error observed on console. In the JSF page we get an error when we try >>>>> to load the pm.js using the tag >>>>> >>>>> INFO: Added Library from: >>>>> zip:/export/vol02/CFS_Cluster/user_projects/domains/Cluster_AutoDomain/. >>>>> /servers/ManagedServer_1/stage/chordiant/chordiant/Advisor/WEB-INF/lib/t >>>>> rinidad-impl-1.0.10.jar!/META-INF/trh.taglib.xml >>>>> <Apr 3, 2009 5:03:36 PM IST> <Error> <WebLogicServer> <BEA-000337> >>>>> <[STUCK] ExecuteThread: '5' for queue: 'weblogic.kernel.Default >>>>> (self-tuning)' has been busy for "616" seconds working on the request >>>>> "Http Request: >>>>> /Advisor/iAdvisorWeb/bundles/profilemanager/scripts/pm.js", which is >>>>> more than the configured time (StuckThreadMaxTime) of "600" seconds. >>>>> Stack trace: >>>>> >>>>> weblogic.servlet.internal.session.ReplicatedSessionContext.getSessionInt >>>>> ernal(ReplicatedSessionContext.java:375) >>>>> >>>>> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.getValidSessi >>>>> on(ServletRequestImpl.java:2521) >>>>> >>>>> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.getSessionInt >>>>> ernal(ServletRequestImpl.java:2090) >>>>> >>>>> weblogic.servlet.internal.ServletRequestImpl$SessionHelper.getSession(Se >>>>> rvletRequestImpl.java:2057) >>>>> >>>>> weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestIm >>>>> pl.java:1189) >>>>> >>>>> weblogic.servlet.security.internal.SecurityModule$SessionRetrievalAction >>>>> .run(SecurityModule.java:535) >>>>> >>>>> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSu >>>>> bject.java:321) >>>>> >>>>> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121 >>>>> ) >>>>> >>>>> weblogic.servlet.security.internal.SecurityModule.getUserSession(Securit >>>>> yModule.java:426) >>>>> >>>>> weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(Se >>>>> rvletSecurityManager.java:81) >>>>> >>>>> weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServ >>>>> letContext.java:1920) >>>>> >>>>> weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletCont >>>>> ext.java:1890) >>>>> >>>>> weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java >>>>> :1344) >>>>> weblogic.work.ExecuteThread.execute(ExecuteThread.java:209) >>>>> weblogic.work.ExecuteThread.run(ExecuteThread.java:181 >>>>> >>>>> Thanks, >>>>> Sabitha >>>>> >>>>> -----Original Message----- >>>>> From: [email protected] [mailto:[email protected]] On Behalf Of >>>>> Matthias Wessendorf >>>>> Sent: Wednesday, April 08, 2009 5:35 PM >>>>> To: MyFaces Development >>>>> Subject: Re: <trh:script> tag causes deadlock on weblogic 9.2 cluster >>>>> >>>>> Hi, >>>>> >>>>> so, the "old" ri is "clean" ? >>>>> What is the dump ? >>>>> >>>>> can you post some more information ? >>>>> >>>>> Also, does this reproduce with a (simple) Trinidad page? >>>>> >>>>> Is it JSP(X) or Facelets ? >>>>> >>>>> -Matthias >>>>> >>>>> On Wed, Apr 8, 2009 at 2:02 PM, Sabitha Gopal Pandit >>>>> <[email protected]> wrote: >>>>>> Hi ALL, >>>>>> >>>>>> >>>>>> >>>>>> We are facing this strange issue. We are in the release phase of our >>>>>> application. >>>>>> >>>>>> >>>>>> >>>>>> Any .jspx containing >>>>>> >>>>>> <trh:script> tag causes deadlock on weblogic 9.2 cluster when used >>>>> with >>>>>> el-impl-1.0.jar. >>>>>> >>>>>> >>>>>> >>>>>> The same trinidad version is working fine when used with old >>>>> el-ri-1.0.jar. >>>>>> >>>>>> >>>>>> >>>>>> Note: Every thing works fine if deployed on non-clustered weblogic >>>>>> environment. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Environment Details: >>>>>> >>>>>> >>>>>> >>>>>> trinidad-api-1.0.10.jar >>>>>> >>>>>> trinidad-impl-1.0.10.jar >>>>>> >>>>>> el-api-1.0.jar >>>>>> >>>>>> el-impl-1.0.jar >>>>>> >>>>>> jsf-facelets-1.1.14.jar >>>>>> >>>>>> >>>>>> >>>>>> Quick response is very highly appreciated >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Sabitha >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
