Bug 901311 (JBPAPP6-1774)

I came across the link https://community.jboss.org/thread/194882 which suggests 
        <subsystem xmlns="urn:jboss:domain:jmx:1.1">
            <show-model value="true"/>
            <remoting-connector/>
        </subsystem>

could be replaced with
        <subsystem xmlns="urn:jboss:domain:jmx:1.1">
            <show-model value="true"/>
             <jmx-connector server-binding="jmx-connector-server" registry-binding="jmx-connector-registry"/>
         </subsystem>

as well adding

        <socket-binding name="jmx-connector-registry" port="1090" interface="management"/>
         <socket-binding name="jmx-connector-server" port="1091" interface="management"/>

I can see this does not work in the current release. Is this a feature that has since been removed?


JConsole help option shows 
--
connection = pid || host:port || JMX URL (service:jmx:<protocol>://...)
--
JMX URL   - Available in EAP 6.0.1 with URL option service:jmx:remoting-jmx://localhost:9999 . Port offset works i.e -Djboss.socket.binding.port-offset
host:port - Looks like it ties in with https://community.jboss.org/thread/194882 . Even if this feature is returned, can it work with port offset?
pid       - Double-clicking on the pid, with port offset configured, is what results in the NullPointerException reported in this JIRA. It worked in AS 7.1.1

we're double checking with the customer, but it seems a simple matter of doing this to our jconsole scripts:

windows, line 86:

"%JAVA_HOME%\bin\jconsole.exe" -J"-Djava.class.path=%CLASSPATH%" %*

linux, last line:

jconsole -J-Djava.class.path="$CLASSPATH" "$@"

so any params added to the bat/sh script, will be passed to the actual executable.

Customer confirmed the fix didn't work.

I have tried too - 

by altering line 86 to be

  "%JAVA_HOME%\bin\jconsole.exe" -J"-Djava.class.path=%CLASSPATH%" %*


and running eap 6.1.0 (with an offset)

  c:\jboss-eap-6.1\bin>standalone.sh -Djboss.socket.binding.port-offset=100

then running

  c:\jboss-eap-6.1\bin>jconsole.bat 1600 

This appears to pass the pid parameter in but then get 


4-June-2013 11:52:38 org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.7.GA-redhat-1
4-June-2013 11:52:38 org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.7.GA-redhat-1
4-June-2013 11:52:38 org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.14.GA-redhat-1
Exception in thread "AWT-EventQueue-0" java.lang.RuntimeException: Error connecting to JBoss AS.
	at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:80)
	at sun.tools.jconsole.VMPanel.createPluginTabs(VMPanel.java:641)
	at sun.tools.jconsole.VMPanel.propertyChange(VMPanel.java:315)
	at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
	at javax.swing.event.SwingPropertyChangeSupport.firePropertyChange(SwingPropertyChangeSupport.java:75)
	at javax.swing.event.SwingPropertyChangeSupport$1.run(SwingPropertyChangeSupport.java:80)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
	at java.awt.EventQueue.access$000(EventQueue.java:84)
	at java.awt.EventQueue$1.run(EventQueue.java:607)
	at java.awt.EventQueue$1.run(EventQueue.java:605)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Caused by: java.lang.NullPointerException
	at org.jboss.as.cli.gui.JConsoleCLIPlugin.connectCommandContext(JConsoleCLIPlugin.java:109)
	at org.jboss.as.cli.gui.JConsoleCLIPlugin.getTabs(JConsoleCLIPlugin.java:77)
	... 19 more

Cant reproduce in 6.1.x branch. Need info about env or this will be closed as "WORKSFORME"

Just tried Wildfly 8 alpha
On windows running

  c:\wildfly-8.0.0.Alpha1\bin>standalone.sh -Djboss.socket.binding.port-offset=100

then running

  c:\wildfly-8.0.0.Alpha1\bin>jconsole.bat <pid>

(so no changes, straight out of the box)

and I get similar errors (sorry couldn't paste as it's on diff machine).

Bartosz Baranowski <bbaranow> made a comment on jira WFLY-1548

There is PR in wfly in pool. Why if its not "Remoting" integration should be disabled?

Darran Lofthouse <darran.lofthouse> made a comment on jira WFLY-1548

If a user has decided to connect directly to the WildFly process without a Remoting connection why should we then go ahead and open a Remoting connection?

Secondly this may work whilst the local authentication mechanism is enabled but what about situations where this is disabled and a username password prompt is now required?

Not sure why this has a dev ack as I have already removed it once.

I do not agree that there should be any attempt to automatically connect to the server if the user has chosen a local connection, the moment we move away from local authentication any attempts to automatically connect fail as there is no mechanism to obtain the users username and password.

Where jconsole is connected to the process locally I suggest two alternatives: -

 - Add the CLI tab but with a clear message stating why the CLI is not currently available, potentially add an 'Establish Connection' button to the tab with the capability to prompt for a username and password if required and make use of the discovered address.

 - Add an MBean that can handle management ops, the CLI integration can use that MBean regardless of the connection method and would not require the establishment of additional connections.

Due to the domain management implications there would be a few parties interested in this so I suggest we get a new discussion started on the dev list.

However as I have said elsehwere I think this is attempting to fix a 'feature' that should not exist in it's current form anyway and the current approach whilst it fixes the current problem leaves it open for the next issue to be raised against it once something like the authentication requirements are changed.  What we do need is the overall solution that works with the out of the box configuration but is flexible enough to cope with changes to this configuration.

A closely related issue is this one: -

https://issues.jboss.org/browse/WFLY-1146

However WFLY-1146 has a problem in that it depends on internal sun APIs but also has the same problem as this issue in that it breaks as soon as username / password authentication is mandated.

Will this make 6.1.1 ?

As I have said above I do not agree this is even a valid change.

The change being requested here is exactly the kind of change that works around one very specific issue only to lead to more support cases and bug reports against subsequent releases with very minor configuration changes.

For EAP 6.2 I believe the correct approach would be to update the CLI integration as describe above - provide the end user with an option to request a connection and appropriate GUI components to allow end user interaction should authentication be required.

Updated PR in jira: https://github.com/wildfly/wildfly/pull/4974

Bartosz Baranowski <bbaranow> made a comment on jira WFLY-1548

[~darranl] PR has been merged.

Darran Lofthouse <darran.lofthouse> made a comment on jira WFLY-1548

This fix has resulted in a change that has gone into Beta1 so a new Jira will be needed if further work is required.

testing with EAP 6.2.0.Beta1

gives

Nov 07, 2013 8:17:06 PM org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.7.GA-redhat-1
Nov 07, 2013 8:17:06 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.7.GA-redhat-1
Nov 07, 2013 8:17:06 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.16.GA-redhat-1
Exception in thread "VMPanel.connect" java.lang.RuntimeException: Operation failed with status WAITING
	at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:219)
	at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:144)
	at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:95)
	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:267)
	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:226)
	at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:366)
	at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:316)
	at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:298)