[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-3475) New deployment mechanism not working correclty on clustered or multi-server envs.
Galder Zamarreno (JIRA)
jira-events at lists.jboss.org
Tue Jan 20 13:22:04 EST 2009
[ https://jira.jboss.org/jira/browse/JBIDE-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12448844#action_12448844 ]
Galder Zamarreno commented on JBIDE-3475:
-----------------------------------------
Rob,
Re: 3) Use the attached JAVA file (modify it of course) to attempt to use JMX to SHUTDOWN a server on lo3. Remember, there is NO server running on lo3 currently. The only server running is on lo2.
I believe what is happening is that when lo3 is not accessible, auto discovery kicks in:
"If the property string java.naming.provider.url is empty or if all servers it mentions are not reachable, the JNP client will try to discover a bootstrap HA-JNDI server through a multicast call on the network (auto-discovery). "
So, lo2 would reply to JNDI multicast discovery and hence that's how the shutdown call lands on lo2.
http://docs.jboss.com/jbossas/guides/clusteringguide/r2/en/html_single/#clustering-jndi
Here's a more detailed client log for you to inspect:
2009-01-20 19:19:51,093 1 DEBUG [org.jnp.interfaces.NamingContext] (main:) Failed to connect to lo3:1099
javax.naming.CommunicationException: Failed to connect to server lo3:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server lo3:1099 [Root exception is java.net.ConnectException: Connection refused]]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:274)
at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1533)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
at javax.naming.InitialContext.lookup(InitialContext.java:351)
at com.acme.jmx.ShutdownTest.test000(ShutdownTest.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: javax.naming.ServiceUnavailableException: Failed to connect to server lo3:1099 [Root exception is java.net.ConnectException: Connection refused]
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:248)
... 21 more
Caused by: java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:520)
at java.net.Socket.connect(Socket.java:470)
at java.net.Socket.<init>(Socket.java:367)
at java.net.Socket.<init>(Socket.java:267)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84)
at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77)
at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:244)
... 21 more
2009-01-20 19:19:51,099 7 TRACE [org.jnp.interfaces.NamingContext] (main:) TTL on multicast discovery socket is 16
2009-01-20 19:19:51,099 7 TRACE [org.jnp.interfaces.NamingContext] (main:) MulticastSocket: java.net.MulticastSocket at f0c0d3
2009-01-20 19:19:51,099 7 TRACE [org.jnp.interfaces.NamingContext] (main:) Sending discovery packet(GET_ADDRESS) to: /230.0.0.4:1102
2009-01-20 19:19:51,102 10 TRACE [org.jnp.interfaces.NamingContext] (main:) Received answer packet: 127.0.0.2:1100
2009-01-20 19:19:51,219 127 TRACE [org.jboss.ha.framework.interfaces.HARMIClient] (main:) Init, clusterInfo: org.jboss.ha.framework.interfaces.FamilyClusterInfoImpl at 2f549848{familyName=DefaultPartition/HAJNDI,targets=[HARMIServerImpl_Stub[UnicastRef2 [liveRef: [endpoint:[lo2:1101](remote),objID:[-606492d7:11ef5448e9a:-7fe8, 9137209410287297649]]]]],currentViewId=-7315973,isViewMembersInSyncWithViewId=false,cursor=999999999,arbitraryObject=null}, policy=org.jboss.ha.framework.interfaces.RoundRobin at e1899b
2009-01-20 19:19:51,222 130 TRACE [org.jboss.ha.framework.interfaces.HARMIClient] (main:) Invoking on target=HARMIServerImpl_Stub[UnicastRef2 [liveRef: [endpoint:[lo2:1101](remote),objID:[-606492d7:11ef5448e9a:-7fe8, 9137209410287297649]]]]
2009-01-20 19:19:51,303 211 DEBUG [org.jboss.security.SecurityAssociation] (main:) Using ThreadLocal: false
2009-01-20 19:19:51,305 213 TRACE [org.jboss.security.SecurityAssociation] (main:) getPrincipal, principal=null
This needs to be taken into account when deploying something, you should be using the hostname of the server
to hit that server and avoid your deploy call landing on a different node due to naming url host not being available.
> New deployment mechanism not working correclty on clustered or multi-server envs.
> ---------------------------------------------------------------------------------
>
> Key: JBIDE-3475
> URL: https://jira.jboss.org/jira/browse/JBIDE-3475
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JBossAS
> Affects Versions: 3.0.0.CR2
> Reporter: Galder Zamarreno
> Assignee: Snjezana Peco
> Priority: Blocker
> Fix For: 3.0.0.CR2
>
> Attachments: 20090116.zip, acme-haejb2.jar, jbide3475.zip, mainOutput.txt, MyMain.java, server.log
>
>
> There's something not working correctly with the new deployment mechanism:
> I have a cluster of 2 nodes with an clustered EJB3 application deployed (SLSBs, SFSBs, Entities...etc).
> When I start the 1st node, it works perfectly and after startup being completed, ear is deployed without
> any issues.
> After deployment is complete, I start the 2nd node and the EJB3 application is deployed again in the 1st
> node and the 2nd node has no deployment whatsoever.
> See attached logs + ear app.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbosstools-issues
mailing list