You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Eoghan Glynn <eo...@gmail.com> on 2009/09/07 12:33:56 UTC
[Karaf] admin:create'd instance launched from the command line
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)
Re: [Karaf] admin:create'd instance launched from the command line
Posted by Guillaume Nodet <gn...@gmail.com>.
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<eo...@gmail.com> 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 <gn...@gmail.com>
>
>> 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 <eo...@gmail.com> 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
Re: [Karaf] admin:create'd instance launched from the command line
Posted by Eoghan Glynn <eo...@gmail.com>.
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 <gn...@gmail.com>
> 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 <eo...@gmail.com> 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
>
Re: [Karaf] admin:create'd instance launched from the command line
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <eo...@gmail.com> 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