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

[glassfishrobot]

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.

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)

Affected Versions

[4.0_dev]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/17848
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented hvilekar said: 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.

[glassfishrobot]

@glassfishrobot Commented liang.x.zhao said: 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.

[glassfishrobot]

@glassfishrobot Commented hvilekar said: 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.

[glassfishrobot]

@glassfishrobot Commented oleksiys said: 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

[glassfishrobot]

@glassfishrobot Commented hvilekar said: 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.

[glassfishrobot]

@glassfishrobot Commented Was assigned to hvilekar

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-17848

[glassfishrobot]

@glassfishrobot Commented Reported by oschmitt

[glassfishrobot]

@glassfishrobot Commented Marked as fixed on Sunday, March 3rd 2013, 10:26:01 pm