[
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/%3ce0a702b010ca5f499baad4c2a2ff739f0de65...@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-unsubscr...@xmlbeans.apache.org
For additional commands, e-mail: dev-h...@xmlbeans.apache.org
