XMLBeans
  1. XMLBeans
  2. XMLBEANS-453

XMLBeans creating STUCK threads due to deadlocks

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: XmlObject
    • Labels:
      None
    • Environment:
      Unix, WebLogic 9.2, EJB 2.0

      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.

      1. xbean.jar
        1.82 MB
        Sanat Vij
      2. nameSearchXml.jar
        1.00 MB
        Sanat Vij
      3. NameSearchServiceProcessor.java
        12 kB
        Sanat Vij

        Activity

        Hide
        Sanat Vij added a comment -

        I am unsure oft he version of apache xmlBeans causing this issue, therefore am attaching the xbean.jar used in my application.

        Show
        Sanat Vij added a comment - I am unsure oft he version of apache xmlBeans causing this issue, therefore am attaching the xbean.jar used in my application.
        Hide
        Sanat Vij added a comment -

        Attached xbean.jar causing the issue

        Show
        Sanat Vij added a comment - Attached xbean.jar causing the issue
        Hide
        Sanat Vij added a comment -

        Attached the jar file generated from the compiled schema's.
        Attached the java class wherein the xmlObject is being set.

        Show
        Sanat Vij added a comment - Attached the jar file generated from the compiled schema's. Attached the java class wherein the xmlObject is being set.
        Hide
        Sanat Vij added a comment -

        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.

        Show
        Sanat Vij added a comment - 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.
        Hide
        Sha Art added a comment - - edited

        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)
        Show
        Sha Art added a comment - - edited 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)

          People

          • Assignee:
            Unassigned
            Reporter:
            Sanat Vij
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development