I've fixed this issue as part of FELIX-1575 by simply using a different name for each JMX connector to bind in the RMI registry. Obviously this is not very generic and a better and more generic mechanism such as the one you describe should be implemented at some point.
On Mon, Sep 7, 2009 at 21:47, Eoghan Glynn<[email protected]> wrote: > Hi Guillaume, > > For the special case of the JMX URI, I wonder would something like the > following approach work: > > - allow a parameter to admin:create to specify some extra system > property/ies > > - pass those property/ies to the JVM launched via the generated > instances/<name>/bin/karaf script > > - use this mechanism to over-ride the default 1099 port via the > com.sun.management.jmxremote.port system property when admin:creating a > karaf instance that should be managable > > - if the karaf instance is not explicitly considered managable, then disable > the JMX connector by default to avoid the port clash > > The reason I suggest "com.sun.management.jmxremote.port", as opposed to some > Karaf-specific system property, as AFAIK this property is auto-detected by > tools such as Hyperic (which does a process table query and thus has > visibility over any properties set on the command line via the java -D > option). > > Cheers, > Eoghan > > > 2009/9/7 Guillaume Nodet <[email protected]> > >> Right, currently, the sshd port for child instances is managed by the >> commands, but RMI and HTTP or any other port aren't. >> I think it can be done through the command line by connecting to the child >> instance and updating the configurations for the config admin, but it's >> really tedious and a better way need to be found. >> >> I guess we'd need a generic mechanism to handle port conflicts, not sure >> what's the best way yet. >> >> Thoughts welcomed ! >> >> On Mon, Sep 7, 2009 at 12:33, Eoghan Glynn <[email protected]> wrote: >> >> > Hi Folks, >> > >> > If I launch an admin:create'd instance via admin:start from the master >> > karaf >> > instance, all is hunky-dorey. >> > >> > However, if instead the child instance is run from the command line via >> the >> > generated instances/<name> directory tree, then I'm see a port clash on >> the >> > JMX RMI connector[1] if the master instance is still runing. >> > >> > So I guess the question is, should we automatically override the jmxrmi >> > port >> > for the admin:create'd instance? (presumably via the serviceUrl property >> > picked up by OSGI-INF/blueprint/karaf-management.xml) >> > >> > Or should the JMX RMI connector be disabled for the child instance? (as >> the >> > management tooling may be expecting port 1099 or nothing) >> > >> > We may have a similar issue with the default 8181 port for the HTTP >> > service. >> > >> > Cheers, >> > Eoghan >> > >> > >> > [1] >> > Exception in thread "JMX Connector Thread >> > [service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi]" >> > java.lang.RuntimeException: Could not start JMX connector server >> > at >> > >> > >> org.apache.felix.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:103) >> > Caused by: java.io.IOException: Cannot bind to URL >> > [rmi://localhost:1099/jmxrmi]: javax.naming.NameAlreadyBoundException: >> > jmxrmi [Root exception is java.rmi.AlreadyBoundException: jmxrmi] >> > at >> > >> > >> javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:804) >> > at >> > >> > >> javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:417) >> > at >> > >> > >> org.apache.felix.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:101) >> > Caused by: javax.naming.NameAlreadyBoundException: jmxrmi [Root exception >> > is >> > java.rmi.AlreadyBoundException: jmxrmi] >> > at >> > com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:122) >> > >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
