[jbosstools-issues] [JBoss JIRA] (JBIDE-15297) Error when restarting EAP 5.2 with JMX poller

[Rob Stryker (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12793383#comment-12793383 ] 

Rob Stryker commented on JBIDE-15297:
-------------------------------------

It seems the web port poller decides the server is done very quickly. The server must shut down web applications before it shuts down jmx and the remaining services. WTP recognizes the server is set into 'stopped' mode, and immediately begins to start it again, including launching a new process with a jmx poller. 

The jmx poller sees the server is still responding and so decides early that the server is up. 

Unfortunately I don't think there's anything that can be done here. 

1) The web port poller is functioning properly. Any changes to the web port poller would be incorrect. If the user wanted to wait until process was terminated, they'd use the process terminated poller instead. Adding a random delay also makes no sense. 

2) The WTP code is functioning properly. Once a server is set to 'stopped' it can be 'started' again, and WTP launches the start job immediately. 

3) The JMX poller is functioning properly. It decides the server is up early because the (old) server proceess is still responding. 

4) I do have a method I could override to customize the wtp behavior of restart = stop + start, but there is no obvious logic of what to put in there to make this function better. 

It should just mostly be documented that users should use like-pollers where possible. If a user wants to use web-port poller for shutdown, he should use it for startup to. Same for JMX or as7 management. Combinations such as JMX + web port poller can lead to false positives. 

JBT does not guarantee that all poller combinations will work optimally when mixed with each other for all use cases. The reason we have multiple pollers is if users don't expose certain ports at all, for example, if JMX is not exposed, they may wish to use web port for both startup and shutdown. If AS7 management port is not exposed, users may wish to use web port poller for both. Mixing and matching may work in many cases, but they all work differntly, and the various pollers are offered for users to discover which combinations work best for them. 

Unfortunately I can't see a way to fix this or a way to change any of the individual pollers or workflow without invalidating the logic that the poller is based on. I think I'm going to close this as wont-fix, but add an affects-documentation.  
                
> Error when restarting EAP 5.2 with JMX poller
> ---------------------------------------------
>
>                 Key: JBIDE-15297
>                 URL: https://issues.jboss.org/browse/JBIDE-15297
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 4.1.0.Final
>         Environment: EAP 5.2.0
>            Reporter: Martin Malina
>             Fix For: 4.1.1.Final
>
>
> When you have EAP 5.2 set up to use JMX for startup poller and Web Port for Shutdown poller, when you start and then restart the server, you get this error:
> {code}
> org.jboss.tools.jmx.core.JMXException: Error connecting to remote JMX. Please ensure your server is properly configured for JMX access.
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:156)
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:127)
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:116)
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.connectToStartedServer(JBossServerConnection.java:239)
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection$1.run(JBossServerConnection.java:231)
> 	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
> Caused by: javax.naming.CommunicationException [Root exception is java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: 
> 	java.net.ConnectException: Connection refused]
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:886)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:713)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:411)
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.createConnection(JBossServerConnection.java:170)
> 	at org.jboss.ide.eclipse.as.jmx.integration.JBossServerConnection.run(JBossServerConnection.java:143)
> 	... 5 more
> Caused by: java.rmi.ConnectException: Connection refused to host: localhost; nested exception is: 
> 	java.net.ConnectException: Connection refused
> 	at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
> 	at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
> 	at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
> 	at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:128)
> 	at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:194)
> 	at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:148)
> 	at com.sun.proxy.$Proxy14.lookup(Unknown Source)
> 	at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:753)
> 	... 9 more
> Caused by: java.net.ConnectException: Connection refused
> 	at java.net.PlainSocketImpl.socketConnect(Native Method)
> 	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
> 	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
> 	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
> 	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> 	at java.net.Socket.connect(Socket.java:579)
> 	at java.net.Socket.connect(Socket.java:528)
> 	at java.net.Socket.<init>(Socket.java:425)
> 	at java.net.Socket.<init>(Socket.java:208)
> 	at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:40)
> 	at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:146)
> 	at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
> 	... 16 more
> {code}
> This is a common error indicating you don't have the credentials right, but it's not the case here - on the first start everything was ok.
> In this case when the server is restarting, it is shown in the server view as Started before it actually is started and maybe that's the problem - the tooling then tries to connect via JMX prematurely and fails.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira