glassfish
  1. glassfish
  2. GLASSFISH-4065

Connector configuration lookup not multithread safe

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 9.1peur1
    • Fix Version/s: 9.2, 3.1_b33
    • Component/s: deployment
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      4,065

      Description

      Product: AS8.1, AS8.2 , AS9.x, GFv2ur1 (AS911)
      OS: Not relevant

      Description
      ------------
      Trying to use a standalone client that does a
      lookup to a JMS pool fails. This is
      like continuation to
      https://glassfish.dev.java.net/issues/show_bug.cgi?id=2672
      since there is some other parts of the AS8/AS9 common
      subsystem that is not multithread safe.

      IN short,
      Concurrent lookup of
      lookup(jmspool) on Thread-1
      lookup(jmspool) on Thread-2
      may cause problems.

      Symptom/Testcase
      --------

      1. Create a JMS pool with (MUST be this)

      <connector-connection-pool associate-with-thread="false" connection-creation
      -retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connectio
      n-definition-name="javax.jms.TopicConnectionFactory" connection-leak-reclaim="fa
      lse" connection-leak-timeout-in-seconds="0" fail-all-connections="false" idle-ti
      meout-in-seconds="300" is-connection-validation-required="false" lazy-connection
      -association="false" lazy-connection-enlistment="false" match-connections="true"
      max-connection-usage-count="0" max-pool-size="8" max-wait-time-in-millis="60000
      " name="jms/topicpool" pool-resize-quantity="2" resource-adapter-name="jmsra" st
      eady-pool-size="1" validate-atmost-once-period-in-seconds="0">
      <property name="Password" value="admin"/>
      <property name="ReconnectEnabled" value="true"/>
      <property name="AddressListBehavior" value="RANDOM"/>
      <property name="UserName" value="admin"/>
      <property name="ReconnectInterval" value="60000"/>
      <property name="AddressList" value="mq://localhost:7676/,"/>
      <property name="ReconnectAttempts" value="3"/>
      <property name="AddressListIterations" value="3"/>
      <property name="AddressListIterations" value="3"/>
      </connector-connection-pool>

      2. Run the same program

      import javax.naming.*;
      import java.util.*;

      public class genlook extends Thread
      {
      static String host="localhost";
      static String port="3700";
      static String name="jms/topicpool";

      public void run()
      {
      try

      { Hashtable props = new Hashtable(); props.put("javax.rmi.CORBA.UtilClass", "com.sun.corba.ee.impl.javax.rmi.CORBA.Util"); props.put("org.omg.CORBA.ORBClass", "com.sun.corba.ee.impl.orb.ORBImpl"); props.put("org.omg.CORBA.ORBSingletonClass", "com.sun.corba.ee.impl.orb.ORBSingleton"); props.put("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory"); props.put("java.naming.factory.url.pkgs","com.sun.enterprise.naming"); props.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl"); props.put("org.omg.CORBA.ORBInitialHost", host); props.put("org.omg.CORBA.ORBInitialPort", port); props.put(Context.PROVIDER_URL,"iiop://"+host+":"+port); Context c = new InitialContext(props); c.lookup(name); }

      catch (NamingException e)

      { throw new RuntimeException(e); }

      }

      public static void main(String args[]) throws InterruptedException

      { if (args.length>0) host=args[0]; if (args.length>1) port=args[1]; if (args.length>2) name=args[2]; Thread t1 = new genlook(), t2 = new genlook); t1.start(); t2.start(); t2.join(); t2.join(); }

      }

      3. Run this (as a few times if needed). You may get this

      Caused by: javax.naming.CommunicationException: serial context communication ex
      [Root exception is com.sun.enterprise.connectors.ConnectorRuntimeException:
      Failed to create MCF]
      at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:427)
      at javax.naming.InitialContext.lookup(InitialContext.java:351)
      at genlook.run(genlook.java:30)
      Caused by: com.sun.enterprise.connectors.ConnectorRuntimeException: Failed to
      create MCF
      at
      com.sun.enterprise.naming.factory.ConnectorObjectFactory.getObjectInstance(ConnectorObjectFactory.java:116)
      at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
      at com.sun.enterprise.naming.SerialContext.lookup(SerialContext.java:403)
      ... 2 more

      Cause of failure
      -----------------
      It seems that "com.sun.enterprise.connectors.util.SetMethodAction"
      uses com.sun.enterprise.deployment.EnvironmentProperty
      and this "EnvironmentProperty.setBoundsChecking(true|false)"
      is called every now and then.

      The problem is that for the above ManagedConnectionFactory
      that take in primitive variable may trigger
      "setBoundsChecking(false)" and some thread will call
      "setBoundsChecking(true)". The effect is then that
      if there is multiple threads trying to lookup
      the same pool, the above too make cause the following

      java.lang.IllegalArgumentException: Illegal type for environment properties: [nu
      ll]
      at com.sun.enterprise.deployment.EnvironmentProperty.getObjectFromString
      (EnvironmentProperty.java:255)
      at com.sun.enterprise.deployment.EnvironmentProperty.getValueObject(Envi
      ronmentProperty.java:142)
      at com.sun.enterprise.connectors.util.SetMethodAction.run(SetMethodActio
      n.java:94)
      at com.sun.enterprise.connectors.ActiveOutboundResourceAdapter.createMan
      agedConnectionFactory(ActiveOutboundResourceAdapter.java:290)
      at com.sun.enterprise.connectors.ActiveInboundResourceAdapter.createMana
      gedConnectionFactory(ActiveInboundResourceAdapter.java:320)

      • The cause being "EnvironmentProperty" is not a thread safe function
        so that means SetMethodAction is not threadsafe too.

        Activity

        Hide
        km added a comment -

        Redirecting appropriately.

        Show
        km added a comment - Redirecting appropriately.
        Hide
        Jagadish added a comment -

        I do not see the method call
        "at com.sun.enterprise.deployment.EnvironmentProperty.getValueObject(Envi
        ronmentProperty.java:142)" from SetMethodAction any time during 9.x

        https://glassfish.dev.java.net/source/browse/glassfish/appserv-core/src/java/com/sun/enterprise/connectors/util/SetMethodAction.java?annotate=1.9
        does not have a call to getValueObject.

        Somehow EnvironmentProperty's type is null. Will investigate further.

        Show
        Jagadish added a comment - I do not see the method call "at com.sun.enterprise.deployment.EnvironmentProperty.getValueObject(Envi ronmentProperty.java:142)" from SetMethodAction any time during 9.x https://glassfish.dev.java.net/source/browse/glassfish/appserv-core/src/java/com/sun/enterprise/connectors/util/SetMethodAction.java?annotate=1.9 does not have a call to getValueObject. Somehow EnvironmentProperty's type is null. Will investigate further.
        Hide
        Jagadish added a comment -

        Transferring this to Hong for further investigation as making
        EnvironmentProperty's isBoundsChecking() & setBoundsChecking along with some
        minor changes makes it thread safe

        Show
        Jagadish added a comment - Transferring this to Hong for further investigation as making EnvironmentProperty's isBoundsChecking() & setBoundsChecking along with some minor changes makes it thread safe
        Hide
        Jagadish added a comment -

        Corrected Text :
        Setting EnvironmentProperty's isBoundsChecking() & setBoundsChecking as
        synchronized, along with some minor changes makes it thread safe

        Show
        Jagadish added a comment - Corrected Text : Setting EnvironmentProperty's isBoundsChecking() & setBoundsChecking as synchronized, along with some minor changes makes it thread safe
        Hide
        Hong Zhang added a comment -

        Jagadish, thanks for your investigation on this.

        Show
        Hong Zhang added a comment - Jagadish, thanks for your investigation on this.
        Hide
        Hong Zhang added a comment -

        move under deployment

        Show
        Hong Zhang added a comment - move under deployment
        Hide
        harpreet added a comment -

        Per recommendation of Hong - marking for 9.2.

        Show
        harpreet added a comment - Per recommendation of Hong - marking for 9.2.
        Hide
        sanandal added a comment -

        "Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1
        release whose primary release driver is SailFin.
        This issue will be scrubbed after this release and will be given the right
        priority for the next release."

        Show
        sanandal added a comment - "Reclassifying as P4 because this issue is not deemed "must fix" for this v2.1 release whose primary release driver is SailFin. This issue will be scrubbed after this release and will be given the right priority for the next release."
        Hide
        Hong Zhang added a comment -

        I have made the suggested changes by Jagadish in the deployment code to make the boundsChecking thread safe now.

        Show
        Hong Zhang added a comment - I have made the suggested changes by Jagadish in the deployment code to make the boundsChecking thread safe now.

          People

          • Assignee:
            Hong Zhang
            Reporter:
            gfuser9999
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: