You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by "Sanat Vij (JIRA)" <xm...@xml.apache.org> on 2011/04/09 13:41:06 UTC
[jira] [Created] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
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
xmlBeans is creating deadlocks resulting in STUCK thrads in a multi user environment. This issue may occur randomly, on any 1 managed server in a clustered weblogic environment. 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.
A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ 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 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.
was:
xmlBeans is creating deadlocks resulting in STUCK thrads 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 environment. 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 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.
--
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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ 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 resulting in STUCK thrads 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 environment. 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.
A 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.
was:
xmlBeans is creating deadlocks resulting in STUCK thrads 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 environment. 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.
A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
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 resulting in STUCK thrads 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 environment. 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.
> A 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.
--
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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanat Vij updated XMLBEANS-453:
-------------------------------
Attachment: NameSearchServiceProcessor.java
nameSearchXml.jar
Attached the jar file generated from the compiled schema's.
Attached the java class wherein the xmlObject is being set.
> 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 resulting in STUCK thrads 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 environment. 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.
> A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
> 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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ 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 resulting in STUCK thrads 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 environment. 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.
A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
I would greatly appreciate any help that you can provide me with this matter.
was:
xmlBeans is creating deadlocks resulting in STUCK thrads in a multi user environment. I am unsure of the version of xmlBeans causing this issue, and have therefore attched the xbean.jar. This issue may occur randomly, on any 1 managed server in a clustered weblogic environment. 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.
A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
I would greatly appreciate any help that you can provide me with this matter.
Attached xbean.jar causing the issue
> 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: xbean.jar
>
>
> xmlBeans is creating deadlocks resulting in STUCK thrads 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 environment. 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.
> A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
> 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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ 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 resulting in STUCK thrads 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 environment. 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.
A 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.
was:
xmlBeans is creating deadlocks resulting in STUCK thrads 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 environment. 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.
A 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 resulting in STUCK thrads 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 environment. 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.
> A 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.
--
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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ 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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanat Vij updated XMLBEANS-453:
-------------------------------
Attachment: xbean.jar
I am unsure oft he version of apache xmlBeans causing this issue, therefore am attaching the xbean.jar used in my application.
> 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: xbean.jar
>
>
> xmlBeans is creating deadlocks resulting in STUCK thrads in a multi user environment. This issue may occur randomly, on any 1 managed server in a clustered weblogic environment. 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.
> A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
> 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
[jira] [Comment Edited] (XMLBEANS-453) XMLBeans creating STUCK
threads due to deadlocks
Posted by "Sha Art (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277819#comment-13277819 ]
Sha Art edited comment on XMLBEANS-453 at 5/17/12 1:58 PM:
-----------------------------------------------------------
We are experiencing similar issue in version 2.5. Has this been fixed already? Can you please tell us the fix version.
Stack trace:
"ExecuteThread: '299' for queue: 'weblogic.kernel.Default'" daemon prio=3 tid=0x030ee500 nid=0x179 in Object.wait() [0x3f3fe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x8198e400> (a org.apache.xmlbeans.impl.common.Mutex)
at java.lang.Object.wait(Object.java:485)
at org.apache.xmlbeans.impl.common.Mutex.acquire(Mutex.java:33)
- locked <0x8198e400> (a org.apache.xmlbeans.impl.common.Mutex)
at org.apache.xmlbeans.impl.common.GlobalLock.acquire(GlobalLock.java:27)
at org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:2052)
was (Author: sarthanari):
We are experiencing similar issue in version 2.5. Has this been fixed already? Can you please tell us the fix version.
Stack trace:
"ExecuteThread: '299' for queue: 'weblogic.kernel.Default'" daemon prio=3 tid=0x030ee500 nid=0x179 in Object.wait() [0x3f3fe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x8198e400> (a org.apache.xmlbeans.impl.common.Mutex)
at java.lang.Object.wait(Object.java:485)
at org.apache.xmlbeans.impl.common.Mutex.acquire(Mutex.java:33)
- locked <0x8198e400> (a org.apache.xmlbeans.impl.common.Mutex)
at org.apache.xmlbeans.impl.common.GlobalLock.acquire(GlobalLock.java:27)
at org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:2052)
at com.att.yoda.order.impl.OrderImpl.setOrderID(Unknown Source)
- locked <0x882fce30> (a org.apache.xmlbeans.impl.store.Locale)
> 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: Trivial
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
[jira] [Commented] (XMLBEANS-453) XMLBeans creating STUCK threads
due to deadlocks
Posted by "Sha Art (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13277819#comment-13277819 ]
Sha Art commented on XMLBEANS-453:
----------------------------------
We are experiencing similar issue in version 2.5. Has this been fixed already? Can you please tell us the fix version.
Stack trace:
"ExecuteThread: '299' for queue: 'weblogic.kernel.Default'" daemon prio=3 tid=0x030ee500 nid=0x179 in Object.wait() [0x3f3fe000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x8198e400> (a org.apache.xmlbeans.impl.common.Mutex)
at java.lang.Object.wait(Object.java:485)
at org.apache.xmlbeans.impl.common.Mutex.acquire(Mutex.java:33)
- locked <0x8198e400> (a org.apache.xmlbeans.impl.common.Mutex)
at org.apache.xmlbeans.impl.common.GlobalLock.acquire(GlobalLock.java:27)
at org.apache.xmlbeans.impl.values.XmlObjectBase.set(XmlObjectBase.java:2052)
at com.att.yoda.order.impl.OrderImpl.setOrderID(Unknown Source)
- locked <0x882fce30> (a org.apache.xmlbeans.impl.store.Locale)
> 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: Trivial
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ 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 resulting in STUCK thrads in a multi user environment. I am unsure of the version of xmlBeans causing this issue, and have therefore attched the xbean.jar. This issue may occur randomly, on any 1 managed server in a clustered weblogic environment. 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.
A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
I would greatly appreciate any help that you can provide me with this matter.
was:
xmlBeans is creating deadlocks resulting in STUCK thrads in a multi user environment. This issue may occur randomly, on any 1 managed server in a clustered weblogic environment. 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.
A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
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: xbean.jar
>
>
> xmlBeans is creating deadlocks resulting in STUCK thrads in a multi user environment. I am unsure of the version of xmlBeans causing this issue, and have therefore attched the xbean.jar. This issue may occur randomly, on any 1 managed server in a clustered weblogic environment. 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.
> A bug XMLBEANS - 388 was created for another deadlocking issue, but im unsure whether the deadlocking issue i am currently facing is due to the same cause.
> 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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XMLBEANS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sanat Vij updated XMLBEANS-453:
-------------------------------
Priority: Trivial (was: Critical)
After upgrading to the latest version of Apache XMLBeans, we are no longer seeing deadlocks in our production environment. Seems like the version of Apache xmlBeans being used in our application was causing deadlocks related to array setters. I am thereby reducing the severity of the bug to trivial, and should be closed if there is no further deadlock incident over the next couple of months. Thanks to Robert J Liguori for his follow up on this issue.
> 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: Trivial
> 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
[jira] [Updated] (XMLBEANS-453) XMLBeans creating STUCK threads due
to deadlocks
Posted by "Sanat Vij (JIRA)" <xm...@xml.apache.org>.
[ 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 resulting in STUCK thrads 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 environment. 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.
was:
xmlBeans is creating deadlocks resulting in STUCK thrads 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 environment. 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.
A 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 resulting in STUCK thrads 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 environment. 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.
--
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