[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    [jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
From:       "Sanat Vij (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date:       2011-04-09 21:21:05
Message-ID: 240255844.47044.1302384065890.JavaMail.tomcat () hel ! zones ! apache ! org
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/XMLBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Sanat Vij updated XMLBEANS-453:
-------------------------------

    Description: 
xmlBeans is creating deadlocks in a multi user environment. I am unsure of the \
version of xmlBeans causing this issue, and have therefore attached the xbean.jar \
used in my application. This issue may occur randomly, on any 1 managed server in a \
clustered weblogic domain. It results in STUCK threads, causing the EJB to create a \
new bean instance for every incoming request. Once the "Beans In Use Count" (visible \
on weblogic console) reaches its maximum value, the server stops responding. Below is \
a sample of the stacktrace visible in the weblogic server logs:-

<Apr 7, 2011 5:26:56 PM UTC> <Error> <WebLogicServer> <BEA-000337> <[STUCK] \
ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy \
for "653" seconds working on the request \
"com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl", which is more \
than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:  \
java.lang.Object.wait(Native Method)  java.lang.Object.wait(Object.java:474)
        org.apache.xmlbeans.impl.common.Mutex.acquire(Mutex.java:33)
        org.apache.xmlbeans.impl.common.GlobalLock.acquire(GlobalLock.java:27)
        org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:1944)
        com.qwest.xmlSchema.impl.CustomerAccountResponseInfoDocumentImpl$CustomerAccountResponseInfoImpl.setBillingInfo(Unknown \
                Source)
        com.qwest.online.services.processor.cns.NameSearchServiceProcessor.buildSuccessResponse(NameSearchServiceProcessor.java:163)
                
        com.qwest.online.services.processor.cns.NameSearchServiceProcessor.processParsedMessage(NameSearchServiceProcessor.java:96)
                
        com.qwest.online.services.processor.OnlineSvcMessageProcessor.processMessage(OnlineSvcMessageProcessor.java:120)
                
        com.qwest.online.services.processor.OnlineSvcDispatchProcessor.processMessage(OnlineSvcDispatchProcessor.java:29)
                
        com.qwest.online.services.business.facade.OnlineSvcManagerHelper.process(OnlineSvcManagerHelper.java:31)
                
        com.qwest.online.services.business.facade.OnlineSvcManager.process(OnlineSvcManager.java:27)
                
        com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl.process(OnlineSvcMgr_tcpc4g_EOImpl.java:60)
                
        com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl_WLSkel.invoke(Unknown \
                Source)
        weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:550)
        weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
                
        weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:440)
        weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
                
        weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
        weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:436)
        weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:58)
        weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:975)
  weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> 

This issue occurs every 3-4 hours and is resolved only when that particular managed \
server is restarted. I have viewed a similar issue reported at :
http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200810.mbox/%3CE0A702B010CA5F499BAAD4C2A2FF739F0DE656DD@blackex02.detica.com%3E
 However, there seems to be no solution reported in response to the issue.
The bugs XMLBEANS-388 and XMLBEANS-345 were created for similar deadlocking issues, \
but im unsure whether the deadlocking issue i am currently facing is due to any of \
those causes.

I have attached the jar generated from the xsd schema's and the corresponding java \
code where the setters for the same are being called.

I would greatly appreciate any help that you can provide me with this matter.


  was:
xmlBeans is creating deadlocks in a multi user environment. I am unsure of the \
version of xmlBeans causing this issue, and have therefore attached the xbean.jar \
used in my application. This issue may occur randomly, on any 1 managed server in a \
clustered weblogic domain. It results in STUCK threads, causing the EJB to create a \
new bean instance for every incoming request. Once the "Beans In Use Count" (visible \
on weblogic console) reaches its maximum value, the server stops responding. Below is \
a sample of the stacktrace visible in the weblogic server logs:-

<Apr 7, 2011 5:26:56 PM UTC> <Error> <WebLogicServer> <BEA-000337> <[STUCK] \
ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy \
for "653" seconds working on the request \
"com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl", which is more \
than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:  \
java.lang.Object.wait(Native Method)  java.lang.Object.wait(Object.java:474)
        org.apache.xmlbeans.impl.common.Mutex.acquire(Mutex.java:33)
        org.apache.xmlbeans.impl.common.GlobalLock.acquire(GlobalLock.java:27)
        org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:1944)
        com.qwest.xmlSchema.impl.CustomerAccountResponseInfoDocumentImpl$CustomerAccountResponseInfoImpl.setBillingInfo(Unknown \
                Source)
        com.qwest.online.services.processor.cns.NameSearchServiceProcessor.buildSuccessResponse(NameSearchServiceProcessor.java:163)
                
        com.qwest.online.services.processor.cns.NameSearchServiceProcessor.processParsedMessage(NameSearchServiceProcessor.java:96)
                
        com.qwest.online.services.processor.OnlineSvcMessageProcessor.processMessage(OnlineSvcMessageProcessor.java:120)
                
        com.qwest.online.services.processor.OnlineSvcDispatchProcessor.processMessage(OnlineSvcDispatchProcessor.java:29)
                
        com.qwest.online.services.business.facade.OnlineSvcManagerHelper.process(OnlineSvcManagerHelper.java:31)
                
        com.qwest.online.services.business.facade.OnlineSvcManager.process(OnlineSvcManager.java:27)
                
        com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl.process(OnlineSvcMgr_tcpc4g_EOImpl.java:60)
                
        com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl_WLSkel.invoke(Unknown \
                Source)
        weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:550)
        weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
                
        weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:440)
        weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
                
        weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
        weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:436)
        weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:58)
        weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:975)
  weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
        weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> 

This issue occurs every 3-4 hours and is resolved only when that particular managed \
server is restarted. I have viewed a similar issue reported at :
http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200810.mbox/%3CE0A702B010CA5F499BAAD4C2A2FF739F0DE656DD@blackex02.detica.com%3E
 However, there seems to be no solution reported in response to the issue.
The bugs XMLBEANS-388 and XMLBEANS-345 were created for a similar deadlocking issues, \
but im unsure whether the deadlocking issue i am currently facing is due to any of \
those same causes.

I have attached the jar generated from the xsd schema's and the corresponding java \
code where the setters for the same are being called.

I would greatly appreciate any help that you can provide me with this matter.



> XMLBeans creating STUCK threads due to deadlocks
> ------------------------------------------------
> 
> Key: XMLBEANS-453
> URL: https://issues.apache.org/jira/browse/XMLBEANS-453
> Project: XMLBeans
> Issue Type: Bug
> Components: XmlObject
> Environment: Unix, WebLogic 9.2, EJB 2.0
> Reporter: Sanat Vij
> Priority: Critical
> Attachments: NameSearchServiceProcessor.java, nameSearchXml.jar, xbean.jar
> 
> 
> xmlBeans is creating deadlocks in a multi user environment. I am unsure of the \
> version of xmlBeans causing this issue, and have therefore attached the xbean.jar \
> used in my application. This issue may occur randomly, on any 1 managed server in a \
> clustered weblogic domain. It results in STUCK threads, causing the EJB to create a \
> new bean instance for every incoming request. Once the "Beans In Use Count" \
> (visible on weblogic console) reaches its maximum value, the server stops \
> responding. Below is a sample of the stacktrace visible in the weblogic server \
> logs:- <Apr 7, 2011 5:26:56 PM UTC> <Error> <WebLogicServer> <BEA-000337> <[STUCK] \
> ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy \
> for "653" seconds working on the request \
> "com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl", which is \
> more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace: \
> java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:474)
> org.apache.xmlbeans.impl.common.Mutex.acquire(Mutex.java:33)
> org.apache.xmlbeans.impl.common.GlobalLock.acquire(GlobalLock.java:27)
> org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:1944)
> com.qwest.xmlSchema.impl.CustomerAccountResponseInfoDocumentImpl$CustomerAccountResponseInfoImpl.setBillingInfo(Unknown \
> Source) com.qwest.online.services.processor.cns.NameSearchServiceProcessor.buildSuccessResponse(NameSearchServiceProcessor.java:163)
>  com.qwest.online.services.processor.cns.NameSearchServiceProcessor.processParsedMessage(NameSearchServiceProcessor.java:96)
>  com.qwest.online.services.processor.OnlineSvcMessageProcessor.processMessage(OnlineSvcMessageProcessor.java:120)
>  com.qwest.online.services.processor.OnlineSvcDispatchProcessor.processMessage(OnlineSvcDispatchProcessor.java:29)
>  com.qwest.online.services.business.facade.OnlineSvcManagerHelper.process(OnlineSvcManagerHelper.java:31)
>  com.qwest.online.services.business.facade.OnlineSvcManager.process(OnlineSvcManager.java:27)
>  com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl.process(OnlineSvcMgr_tcpc4g_EOImpl.java:60)
>  com.qwest.online.services.business.facade.OnlineSvcMgr_tcpc4g_EOImpl_WLSkel.invoke(Unknown \
> Source) weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:550)
> weblogic.rmi.cluster.ClusterableServerRef.invoke(ClusterableServerRef.java:224)
> weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:440)
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
>  weblogic.security.service.SecurityManager.runAs(SecurityManager.java:147)
> weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:436)
> weblogic.rmi.internal.BasicServerRef.access$300(BasicServerRef.java:58)
> weblogic.rmi.internal.BasicServerRef$BasicExecuteRequest.run(BasicServerRef.java:975)
>  weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
> weblogic.work.ExecuteThread.run(ExecuteThread.java:181)
> > 
> This issue occurs every 3-4 hours and is resolved only when that particular managed \
> server is restarted. I have viewed a similar issue reported at :
> http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200810.mbox/%3CE0A702B010CA5F499BAAD4C2A2FF739F0DE656DD@blackex02.detica.com%3E
>  However, there seems to be no solution reported in response to the issue.
> The bugs XMLBEANS-388 and XMLBEANS-345 were created for similar deadlocking issues, \
> but im unsure whether the deadlocking issue i am currently facing is due to any of \
> those causes. I have attached the jar generated from the xsd schema's and the \
> corresponding java code where the setters for the same are being called. I would \
> greatly appreciate any help that you can provide me with this matter.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic