Help Desk Ticket Reference: https://c.na7.visual.force.com/apex/Case_View?id=500A000000CR6XgIAL Steps to Reproduce: i) run standalone.bat and ensure there is a port offset of 100 ii) run jconsole.bat Workaround: Workaround Exists Workaround Description: 1) In jconsole.bat comment out the line: REM call :SearchForJars "%JBOSS_MODULEPATH%\org\jboss\as\cli\main" 2) allow jconsole to fail and then connect to a remote connection using: service:jmx:remoting-jmx://localhost:10099 (if the port offset is 100) project_key: JBPAPP6 If trying to connect to a standalone EAP 6.0.1 instance that is run using offset ports ie. with -Djboss.socket.binding.port-offset=100 The following is seen in jconsole after running jconsole.bat: 04-Jan-2013 10:42:02 org.xnio.Xnio <clinit> INFO: XNIO Version 3.0.7.GA-redhat-1 04-Jan-2013 10:42:02 org.xnio.nio.NioXnio <clinit> INFO: XNIO NIO Implementation Version 3.0.7.GA-redhat-1 04-Jan-2013 10:42:02 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:641) at java.awt.EventQueue.access$000(EventQueue.java:84) at java.awt.EventQueue$1.run(EventQueue.java:602) at java.awt.EventQueue$1.run(EventQueue.java:600) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.awt.EventQueue.dispatchEvent(EventQueue.java:611) 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 jconsole itself allows ports to be used - Usage: jconsole [ -interval=n ] [ -notile ] [ -pluginpath <path> ] [ -version ] [ connection ... ] -interval Set the update interval to n seconds (default is 4 seconds) -notile Do not tile windows initially (for two or more connections) -pluginpath Specify the path that jconsole uses to look up the plugins -version Print program version connection = pid || host:port || JMX URL (service:jmx:<protocol>://...) pid The process id of a target process host A remote host name or IP address port The port number for the remote connection -J Specify the input arguments to the Java virtual machine on which jconsole is running But our script prohibits these so in affect jconsole.bat can only be run using the default standalone profile. It would be better if the port offset could be passed to jconsole.bat
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)