[
https://jira.jboss.org/jira/browse/JBIDE-3475?page=com.atlassian.jira.plu...
]
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/#c...
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@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@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@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