glassfish
  1. glassfish
  2. GLASSFISH-17848

Unable to use IIOP listener from local instances deployed into a local cluster

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0_dev
    • Fix Version/s: 4.0_dev
    • Component/s: orb
    • Labels:
      None
    • Environment:

      Glassfish Opne Source Edition 3.1.1 (build 12)
      Mac OS X Snow Leopard (Java build 1.6.0_29-b11-402-10M3527) , Windows 7 (Java 1.6_05)

      Description

      Hi,

      for dev and testing purpose i've tried to use a local cluster with 2 local instances.

      My setup is :

      bash$> asadmin

      Entering asadmin then :

      > create-domain test-cluster
      > start-domain test-cluster
      > copy-config default-config cluster-config
      > create-cluster --config cluster-config cluster-dev
      > create-node-config node1
      > create-node-config node2
      > create-local-instance --node node1 --cluster cluster-dev cluster-inst1
      > create-local-instance --node node2 --cluster cluster-dev cluster-inst2
      > start-cluster cluster-dev
      > create-jms-resource --restype javax.jms.QueueConnectionFactory --target cluster-dev QCF
      > ping-connection-pool QCF
      >

      The QCF is just there to get a thing to lookup through JNDI (i've also tried with Custom JNDI resource like String).

      The cluster starts gracefully.
      Every local instance has HTTP, JMX, ... ports opened but not IIOP ports.
      I can use the JMX connection for every cluster instance , HTTP etc ... (but IIOP).

      Then i built a standard Java client (not using ACC).

      I'm unable to lookup any kind of resource through JNDI and InitialContext : i get a timeout and "could not connect" error on every cluster instance port.

      If i deploy the QCF resource on main server and try to get it through JNDI (3700 port), it works perfectly.

      If i create two separate domains and set two IIOP ports, i can get two running IIOP ports, it works perfectly.

      But it seems that it's impossible (on mac os x and windows 7, not tried on Linux) to have a cluster on a single domain with two local instances and two working IIOP ports (as i said HTTP, JMX, works perfectly).

      Thanks.

        Activity

        Hide
        Harshad Vilekar added a comment -

        This doesn't look like orb issue.

        Try this:
        create-jms-resource --restype javax.jms.QueueConnectionFactory QCF

        Then, use admin to edit QCF - remove target "server", and add target "cluster-dev".

        Then, Simple java client is able to do the lookup, using a command, like:
        java -cp $S1AS_HOME/lib/javaee.jar:$S1AS_HOME/lib/appserv-rt.jar:build/jmsclient -Dorg.omg.CORBA.ORBInitialPort=23700 JMSClient

        Reducing the priority, and changing category to jms - to review if this is a jms issue.

        Show
        Harshad Vilekar added a comment - This doesn't look like orb issue. Try this: create-jms-resource --restype javax.jms.QueueConnectionFactory QCF Then, use admin to edit QCF - remove target "server", and add target "cluster-dev". Then, Simple java client is able to do the lookup, using a command, like: java -cp $S1AS_HOME/lib/javaee.jar:$S1AS_HOME/lib/appserv-rt.jar:build/jmsclient -Dorg.omg.CORBA.ORBInitialPort=23700 JMSClient Reducing the priority, and changing category to jms - to review if this is a jms issue.
        Hide
        David Zhao added a comment -

        I can reproduce it against GF trunk branch (4.0) by following the steps as description above:

        > create-domain test-cluster
        > start-domain test-cluster
        > copy-config default-config cluster-config
        > create-cluster --config cluster-config cluster-dev
        > create-node-config node1
        > create-node-config node2
        > create-local-instance --node node1 --cluster cluster-dev cluster-inst1
        > create-local-instance --node node2 --cluster cluster-dev cluster-inst2
        > start-cluster cluster-dev
        > create-jms-resource --restype javax.jms.QueueConnectionFactory --target cluster-dev QCF
        > ping-connection-pool QCF

        after ping-connection-pool, the ports 23700 is not ready and can not be seen by the command "netstat -an |grep 23700", which means the IIOP listener may be not started up at that time.

        by tracing the svn log, I found the checkin may affect,

        Revision:
        48403
        Time:
        07/28/2011 11:49 PM
        Author:
        oleksiys
        Path:
        main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java (trunk)
        Message:
        + implement task #17114 http://java.net/jira/browse/GLASSFISH-17114 "moving lazy listeners out of GF kernel"

        Forward this back to ORB team for confirmation.

        Show
        David Zhao added a comment - I can reproduce it against GF trunk branch (4.0) by following the steps as description above: > create-domain test-cluster > start-domain test-cluster > copy-config default-config cluster-config > create-cluster --config cluster-config cluster-dev > create-node-config node1 > create-node-config node2 > create-local-instance --node node1 --cluster cluster-dev cluster-inst1 > create-local-instance --node node2 --cluster cluster-dev cluster-inst2 > start-cluster cluster-dev > create-jms-resource --restype javax.jms.QueueConnectionFactory --target cluster-dev QCF > ping-connection-pool QCF after ping-connection-pool, the ports 23700 is not ready and can not be seen by the command "netstat -an |grep 23700", which means the IIOP listener may be not started up at that time. by tracing the svn log, I found the checkin may affect, Revision: 48403 Time: 07/28/2011 11:49 PM Author: oleksiys Path: main/nucleus/core/kernel/src/main/java/com/sun/enterprise/v3/services/impl/GrizzlyService.java (trunk) Message: + implement task #17114 http://java.net/jira/browse/GLASSFISH-17114 "moving lazy listeners out of GF kernel" Forward this back to ORB team for confirmation.
        Hide
        Harshad Vilekar added a comment -

        Reassigning to grizzly-kernel to evaluate revision 48403.

        Above steps work OK on 3.1.x but not on 4.0.

        After starting the cluster, deploying remote ejb on the cluster also fails with 4.0, works OK with 3.1.x

        :
        > start-cluster cluster-dev
        > list-clusters
        cluster-dev running
        Command list-clusters executed successfully.
        > deploy --target cluster-dev Sfulejb.jar
        Application deployed with name Sfulejb.
        Command deploy failed.

        Show
        Harshad Vilekar added a comment - Reassigning to grizzly-kernel to evaluate revision 48403. Above steps work OK on 3.1.x but not on 4.0. After starting the cluster, deploying remote ejb on the cluster also fails with 4.0, works OK with 3.1.x : > start-cluster cluster-dev > list-clusters cluster-dev running Command list-clusters executed successfully. > deploy --target cluster-dev Sfulejb.jar Application deployed with name Sfulejb. Command deploy failed.
        Hide
        oleksiys added a comment -

        It's not a Grizzly issue.
        IIOP listener is getting initialized by Grizzly only when this listener is in lazy mode (lazy-init parameter is set to true)

              <iiop-service>
                <iiop-listener port="3700" id="orb-listener-1" address="0.0.0.0" *lazy-init="true"*></iiop-listener>
        ........
        

        If lazy-init parameter is not set - ORB is becoming responsible to startup the listener.
        As you can see the default domain.xml/iiop-listener has lazy-init parameter set to true, but one in the node does not. That's why this listener is not getting started by Grizzly. See the OrbConnectorStartup.java line 171

        Show
        oleksiys added a comment - It's not a Grizzly issue. IIOP listener is getting initialized by Grizzly only when this listener is in lazy mode (lazy-init parameter is set to true) <iiop-service> <iiop-listener port= "3700" id= "orb-listener-1" address= "0.0.0.0" *lazy-init= "true" *> </iiop-listener> ........ If lazy-init parameter is not set - ORB is becoming responsible to startup the listener. As you can see the default domain.xml/iiop-listener has lazy-init parameter set to true, but one in the node does not. That's why this listener is not getting started by Grizzly. See the OrbConnectorStartup.java line 171
        Hide
        Harshad Vilekar added a comment -

        Works OK with 4.0-b77. IIOP listeners on the clustered instances are started "after" the app is deployed on the cluster.

        After the last step, try:

        $ asadmin deploy --target cluster-dev Sfulejb.jar
        Application deployed with name Sfulejb.
        Command deploy executed successfully.
        $ netstat -an
        tcp6 0 0 :::23700 :::* LISTEN
        tcp6 0 0 :::3700 :::* LISTEN
        tcp6 0 0 :::23701 :::* LISTEN

        oschmitt, Please confirm if this works for you.

        Show
        Harshad Vilekar added a comment - Works OK with 4.0-b77. IIOP listeners on the clustered instances are started "after" the app is deployed on the cluster. After the last step, try: $ asadmin deploy --target cluster-dev Sfulejb.jar Application deployed with name Sfulejb. Command deploy executed successfully. $ netstat -an tcp6 0 0 :::23700 :::* LISTEN tcp6 0 0 :::3700 :::* LISTEN tcp6 0 0 :::23701 :::* LISTEN oschmitt, Please confirm if this works for you.

          People

          • Assignee:
            Harshad Vilekar
            Reporter:
            oschmitt
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: