[jira] [Updated] (KARAF-3887) JMXRMI over SSL - Exceptions on Karaf Shutdown
[
https://issues.apache.org/jira/browse/KARAF-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Taeschner updated KARAF-3887:
-
Attachment: org.apache.karaf.management.cfg
keystore.xml
keys.properties
karaf.jmx.ssl.jks
added JMX SSL config
JMXRMI over SSL - Exceptions on Karaf Shutdown
--
Key: KARAF-3887
URL: https://issues.apache.org/jira/browse/KARAF-3887
Project: Karaf
Issue Type: Bug
Components: karaf-management
Affects Versions: 2.4.3
Reporter: Michael Taeschner
Attachments: karaf.jmx.ssl.jks, keys.properties, keystore.xml,
org.apache.karaf.management.cfg
We are using JMXRMI over SSL connector as described at JBoss Fuse 6
documentation [1]. This has worked flawlessly with Karaf 2.4.1 (as base for
ServiceMix 4.5.0) but causes exceptions on container shutdown for version
2.4.3. During runtime the SSL connector is working though as before.
Exceptions: StackTrace 1
{noformat}Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException: Could not start JMX connector server
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:272)
Caused by: java.io.IOException: Cannot bind to URL
[rmi://0.0.0.0:1099/karaf-root]: javax.naming.CommunicationException [Root
exception is java.rmi.NoSuchObjectException: no such object in table]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:259)
Caused by: javax.naming.CommunicationException [Root exception is
java.rmi.NoSuchObjectException: no such object in table]
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:147)
at
com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:228)
at javax.naming.InitialContext.bind(InitialContext.java:425)
at
javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
... 1 more
Caused by: java.rmi.NoSuchObjectException: no such object in table
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:379)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:141)
... 5 more
{noformat}
StackTrace 2
{noformat}
Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException:
Port already in use: 4;
You may have started two containers. If you need to start a second container
or the default ports are already in use update the config file
etc/org.apache.karaf.management.cfg and change the Registry Port and Server
Port to unused ports
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:268)
{noformat}
The issue can be recreated using stock Karaf download with the following
steps:
- copy attached keystore.xml and org.apache.felix.fileinstall-keystore.cfg to
./etc folder
- copy self-signed keystore file (karaf.jmx.ssl.jks) to etc folder
- modify etc/org.apache.karaf.management.cfg as shown below (or use modified
copy attached to issue)
- run container, check exceptions on shutdown
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-3888) Karaf refreshes a lot of unrelated bundles during feature installation
[
https://issues.apache.org/jira/browse/KARAF-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ievgen Tarasov updated KARAF-3888:
--
Description:
To reproduce the problem:
{noformat}
feature:repo-add mvn:org.apache.cxf.karaf/apache-cxf/3.1.1/xml/features
feature:repo-add mvn:org.apache.camel.karaf/apache-camel/2.15.2/xml/features
feature:repo-add
mvn:org.apache.activemq/activemq-karaf/5.11-SNAPSHOT/xml/features
feature:install activemq
feature:install activemq-client
feature:install camel
feature:install cxf
feature:install -v -t cxf-ws-policy
{noformat}
The result of the last command is in file [^karaf-refresh-problem] which is
attached to this bug. In short:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
Bundles to refresh:
activemq-karaf/5.11.0.SNAPSHOT (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
javax.mail/1.4.4 (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
jline/2.12.1 (Wired to org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT
which is being refreshed)
net.sf.ehcache/2.9.0 (Wired to org.apache.aries.transaction.manager/1.0.0
which is being refreshed)
(about 90 other bundles)
karaf@root()
{noformat}
In the same time, if I slightly change the order of feature installation
(install activemq-client _before_ activemq), then the refresh doesn't happen:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
karaf@root()
{noformat}
Note regarding AMQ vesrion - I'm using 5.11-SNAPSHOT because of a fix for
another bundle refresh problem: https://issues.apache.org/jira/browse/AMQ-5821
was:
To reproduce the problem:
{noformat}
feature:repo-add mvn:org.apache.cxf.karaf/apache-cxf/3.1.1/xml/features
feature:repo-add mvn:org.apache.camel.karaf/apache-camel/2.15.2/xml/features
feature:repo-add
mvn:org.apache.activemq/activemq-karaf/5.11-SNAPSHOT/xml/features
feature:install activemq
feature:install activemq-client
feature:install camel
feature:install cxf
feature:install -v -t cxf-ws-policy
{noformat}
The result of the last command is in file karaf-refresh-problem which is
attached to this bug. In short:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
Bundles to refresh:
activemq-karaf/5.11.0.SNAPSHOT (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
javax.mail/1.4.4 (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
jline/2.12.1 (Wired to org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT
which is being refreshed)
net.sf.ehcache/2.9.0 (Wired to org.apache.aries.transaction.manager/1.0.0
which is being refreshed)
(about 90 other bundles)
karaf@root()
{noformat}
In the same time, if I slightly change the order of feature installation
(install activemq-client _before_ activemq), then the refresh doesn't happen:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
karaf@root()
{noformat}
Note regarding AMQ vesrion - I'm using 5.11-SNAPSHOT because of a fix for
another bundle refresh problem: https://issues.apache.org/jira/browse/AMQ-5821
Karaf refreshes a lot of unrelated bundles during feature installation
--
Key: KARAF-3888
URL: https://issues.apache.org/jira/browse/KARAF-3888
Project: Karaf
Issue Type: Bug
Components: karaf-feature
Affects Versions: 4.0.0
Reporter: Ievgen Tarasov
Attachments: karaf-refresh-problem
To reproduce the problem:
{noformat}
feature:repo-add mvn:org.apache.cxf.karaf/apache-cxf/3.1.1/xml/features
feature:repo-add mvn:org.apache.camel.karaf/apache-camel/2.15.2/xml/features
feature:repo-add
mvn:org.apache.activemq/activemq-karaf/5.11-SNAPSHOT/xml/features
feature:install activemq
feature:install activemq-client
feature:install camel
feature:install cxf
feature:install -v -t cxf-ws-policy
{noformat}
The result of the last command is in file [^karaf-refresh-problem] which is
attached to this bug. In short:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
Bundles to refresh:
activemq-karaf/5.11.0.SNAPSHOT (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
javax.mail/1.4.4 (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
jline/2.12.1 (Wired to org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT
which is being refreshed)
net.sf.ehcache/2.9.0
[jira] [Created] (KARAF-3887) JMXRMI over SSL - Exceptions on Karaf Shutdown
Michael Taeschner created KARAF-3887:
Summary: JMXRMI over SSL - Exceptions on Karaf Shutdown
Key: KARAF-3887
URL: https://issues.apache.org/jira/browse/KARAF-3887
Project: Karaf
Issue Type: Bug
Components: karaf-management
Affects Versions: 2.4.3
Reporter: Michael Taeschner
We are using JMXRMI over SSL connector as described at JBoss Fuse 6
documentation [1]. This has worked flawlessly with Karaf 2.4.1 (as base for
ServiceMix 4.5.0) but causes exceptions on container shutdown for version
2.4.3. During runtime the SSL connector is working though as before.
Exceptions: StackTrace 1
{noformat}Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException: Could not start JMX connector server
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:272)
Caused by: java.io.IOException: Cannot bind to URL
[rmi://0.0.0.0:1099/karaf-root]: javax.naming.CommunicationException [Root
exception is java.rmi.NoSuchObjectException: no such object in table]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:259)
Caused by: javax.naming.CommunicationException [Root exception is
java.rmi.NoSuchObjectException: no such object in table]
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:147)
at
com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:228)
at javax.naming.InitialContext.bind(InitialContext.java:425)
at
javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
... 1 more
Caused by: java.rmi.NoSuchObjectException: no such object in table
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:379)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:141)
... 5 more
{noformat}
StackTrace 2
{noformat}
Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException:
Port already in use: 4;
You may have started two containers. If you need to start a second container
or the default ports are already in use update the config file
etc/org.apache.karaf.management.cfg and change the Registry Port and Server
Port to unused ports
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:268)
{noformat}
The issue can be recreated using stock Karaf download with the following steps:
- copy attached keystore.xml and org.apache.felix.fileinstall-keystore.cfg to
./etc folder
- copy self-signed keystore file (karaf.jmx.ssl.jks) to etc folder
- modify etc/org.apache.karaf.management.cfg as shown below (or use modified
copy attached to issue)
- run container, check exceptions on shutdown
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-3888) Karaf refreshes a lot of unrelated bundles during feature installation
[
https://issues.apache.org/jira/browse/KARAF-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ievgen Tarasov updated KARAF-3888:
--
Attachment: karaf-refresh-problem
Karaf refreshes a lot of unrelated bundles during feature installation
--
Key: KARAF-3888
URL: https://issues.apache.org/jira/browse/KARAF-3888
Project: Karaf
Issue Type: Bug
Components: karaf-feature
Affects Versions: 4.0.0
Reporter: Ievgen Tarasov
Attachments: karaf-refresh-problem
To reproduce the problem:
{noformat}
feature:repo-add mvn:org.apache.cxf.karaf/apache-cxf/3.1.1/xml/features
feature:repo-add mvn:org.apache.camel.karaf/apache-camel/2.15.2/xml/features
feature:repo-add
mvn:org.apache.activemq/activemq-karaf/5.11-SNAPSHOT/xml/features
feature:install activemq
feature:install activemq-client
feature:install camel
feature:install cxf
feature:install -v -t cxf-ws-policy
{noformat}
The result of the last command is in file karaf-refresh-problem which is
attached to this bug. In short:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
Bundles to refresh:
activemq-karaf/5.11.0.SNAPSHOT (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
javax.mail/1.4.4 (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
jline/2.12.1 (Wired to org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT
which is being refreshed)
net.sf.ehcache/2.9.0 (Wired to org.apache.aries.transaction.manager/1.0.0
which is being refreshed)
(about 90 other bundles)
karaf@root()
{noformat}
In the same time, if I slightly change the order of feature installation
(install activemq-client _before_ activemq), then the refresh doesn't happen:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
karaf@root()
{noformat}
Note regarding AMQ vesrion - I'm using 5.11-SNAPSHOT because of a fix for
another bundle refresh problem: https://issues.apache.org/jira/browse/AMQ-5821
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-3887) JMXRMI over SSL - Exceptions on Karaf Shutdown
[
https://issues.apache.org/jira/browse/KARAF-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Taeschner updated KARAF-3887:
-
Description:
We are using JMXRMI over SSL connector as described at JBoss Fuse 6
documentation [1]. This has worked flawlessly with Karaf 2.4.1 (as base for
ServiceMix 4.5.0) but causes exceptions on container shutdown for version
2.4.3. During runtime the SSL connector is working though as before.
Exceptions: StackTrace 1
{noformat}Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException: Could not start JMX connector server
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:272)
Caused by: java.io.IOException: Cannot bind to URL
[rmi://0.0.0.0:1099/karaf-root]: javax.naming.CommunicationException [Root
exception is java.rmi.NoSuchObjectException: no such object in table]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:259)
Caused by: javax.naming.CommunicationException [Root exception is
java.rmi.NoSuchObjectException: no such object in table]
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:147)
at
com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:228)
at javax.naming.InitialContext.bind(InitialContext.java:425)
at
javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:644)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:427)
... 1 more
Caused by: java.rmi.NoSuchObjectException: no such object in table
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:276)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:253)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:379)
at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source)
at
com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:141)
... 5 more
{noformat}
StackTrace 2
{noformat}
Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException:
Port already in use: 4;
You may have started two containers. If you need to start a second container
or the default ports are already in use update the config file
etc/org.apache.karaf.management.cfg and change the Registry Port and Server
Port to unused ports
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:268)
{noformat}
etc/org.apache.karaf.management.cfg#ObjectName
{code:text}
#
# The ObjectName used to register the JMXConnectorServer
#
objectName = connector:name=rmi
keyStoreAvailabilityTimeout = 5000
keyStore = karaf.keystore
# keyAlias maps to keystore.xml keyPasswords alias
keyAlias = local-test
secured = true
authenticatorType = password
trustStore = karaf.keystore
secureAlgorithm = default
secureProtocol = SSL
{code}
The issue can be recreated using stock Karaf download with the following steps:
- copy attached keystore.xml and org.apache.felix.fileinstall-keystore.cfg to
./etc folder
- copy self-signed keystore file (karaf.jmx.ssl.jks) to etc folder
- modify etc/org.apache.karaf.management.cfg as shown below (or use modified
copy attached to issue)
- run container, check exceptions on shutdown
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.0/html/Security_Guide/files/ESBSecurityJmxSSL.html
was:
We are using JMXRMI over SSL connector as described at JBoss Fuse 6
documentation [1]. This has worked flawlessly with Karaf 2.4.1 (as base for
ServiceMix 4.5.0) but causes exceptions on container shutdown for version
2.4.3. During runtime the SSL connector is working though as before.
Exceptions: StackTrace 1
{noformat}Exception in thread JMX Connector Thread
[service:jmx:rmi://0.0.0.0:4/jndi/rmi://0.0.0.0:1099/karaf-root]
java.lang.RuntimeException: Could not start JMX connector server
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:272)
Caused by: java.io.IOException: Cannot bind to URL
[rmi://0.0.0.0:1099/karaf-root]: javax.naming.CommunicationException [Root
exception is java.rmi.NoSuchObjectException: no such object in table]
at
javax.management.remote.rmi.RMIConnectorServer.newIOException(RMIConnectorServer.java:827)
at
javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:432)
at
org.apache.karaf.management.ConnectorServerFactory$1.run(ConnectorServerFactory.java:259)
Caused by:
[jira] [Commented] (KARAF-3649) instance:list causes IllegalStateException: No session available
[
https://issues.apache.org/jira/browse/KARAF-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642783#comment-14642783
]
Paolo Antinori commented on KARAF-3649:
---
I have seen this as well and I have also noticed that it goes away if you
upgrade to {{sshd-core/0.14.0}}
instance:list causes IllegalStateException: No session available
--
Key: KARAF-3649
URL: https://issues.apache.org/jira/browse/KARAF-3649
Project: Karaf
Issue Type: Bug
Affects Versions: 3.0.3
Reporter: Martin Lichtin
Assignee: Jean-Baptiste Onofré
Priority: Minor
Just executing instance:list causes following exception:
{noformat}
2015-04-08 10:14:58,860 | INFO | 4]-nio2-thread-8 | ServerSession
| 28 - org.apache.sshd.core - 0.12.0 | Server session created from
/127.0.0.1:58539
2015-04-08 10:14:58,864 | INFO | 4]-nio2-thread-8 | Nio2Session
| 28 - org.apache.sshd.core - 0.12.0 | Exception handler threw
exception, closing the session
java.lang.IllegalStateException: No session available
at
org.apache.sshd.common.AbstractSessionIoHandler.exceptionCaught(AbstractSessionIoHandler.java:49)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.io.nio2.Nio2Session.exceptionCaught(Nio2Session.java:126)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.io.nio2.Nio2Session.access$500(Nio2Session.java:47)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.io.nio2.Nio2Session$2.onFailed(Nio2Session.java:230)
at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler$2.run(Nio2CompletionHandler.java:41)
at java.security.AccessController.doPrivileged(Native
Method)[:1.8.0_25]
at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler.failed(Nio2CompletionHandler.java:39)[28:org.apache.sshd.core:0.12.0]
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:128)[:1.8.0_25]
at sun.nio.ch.Invoker.invokeDirect(Invoker.java:157)[:1.8.0_25]
at
sun.nio.ch.UnixAsynchronousSocketChannelImpl.implWrite(UnixAsynchronousSocketChannelImpl.java:736)[:1.8.0_25]
at
sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:382)[:1.8.0_25]
at
sun.nio.ch.AsynchronousSocketChannelImpl.write(AsynchronousSocketChannelImpl.java:399)[:1.8.0_25]
at
java.nio.channels.AsynchronousSocketChannel.write(AsynchronousSocketChannel.java:577)[:1.8.0_25]
at
org.apache.sshd.common.io.nio2.Nio2Session.startWriting(Nio2Session.java:212)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.io.nio2.Nio2Session.write(Nio2Session.java:115)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.session.AbstractSession.doWritePacket(AbstractSession.java:508)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.session.AbstractSession.writePacket(AbstractSession.java:495)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.session.AbstractSession.sendKexInit(AbstractSession.java:856)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.server.session.ServerSession.sendKexInit(ServerSession.java:128)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.server.session.ServerSession.init(ServerSession.java:60)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.server.session.SessionFactory.doCreateSession(SessionFactory.java:43)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.session.AbstractSessionFactory.createSession(AbstractSessionFactory.java:38)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.AbstractSessionIoHandler.sessionCreated(AbstractSessionIoHandler.java:36)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:127)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.io.nio2.Nio2Acceptor$AcceptCompletionHandler.onCompleted(Nio2Acceptor.java:108)[28:org.apache.sshd.core:0.12.0]
at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler$1.run(Nio2CompletionHandler.java:32)
at java.security.AccessController.doPrivileged(Native
Method)[:1.8.0_25]
at
org.apache.sshd.common.io.nio2.Nio2CompletionHandler.completed(Nio2CompletionHandler.java:30)[28:org.apache.sshd.core:0.12.0]
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:126)[:1.8.0_25]
at sun.nio.ch.Invoker$2.run(Invoker.java:218)[:1.8.0_25]
at
sun.nio.ch.AsynchronousChannelGroupImpl$1.run(AsynchronousChannelGroupImpl.java:112)[:1.8.0_25]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_25]
at
[jira] [Created] (KARAF-3888) Karaf refreshes a lot of unrelated bundles during feature installation
Ievgen Tarasov created KARAF-3888:
-
Summary: Karaf refreshes a lot of unrelated bundles during feature
installation
Key: KARAF-3888
URL: https://issues.apache.org/jira/browse/KARAF-3888
Project: Karaf
Issue Type: Bug
Components: karaf-feature
Affects Versions: 4.0.0
Reporter: Ievgen Tarasov
To reproduce the problem:
{noformat}
feature:repo-add mvn:org.apache.cxf.karaf/apache-cxf/3.1.1/xml/features
feature:repo-add mvn:org.apache.camel.karaf/apache-camel/2.15.2/xml/features
feature:repo-add
mvn:org.apache.activemq/activemq-karaf/5.11-SNAPSHOT/xml/features
feature:install activemq
feature:install activemq-client
feature:install camel
feature:install cxf
feature:install -v -t cxf-ws-policy
{noformat}
The result of the last command is in file karaf-refresh-problem which is
attached to this bug. In short:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
Bundles to refresh:
activemq-karaf/5.11.0.SNAPSHOT (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
javax.mail/1.4.4 (Wired to
org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT which is being refreshed)
jline/2.12.1 (Wired to org.apache.activemq.activemq-osgi/5.11.0.SNAPSHOT
which is being refreshed)
net.sf.ehcache/2.9.0 (Wired to org.apache.aries.transaction.manager/1.0.0
which is being refreshed)
(about 90 other bundles)
karaf@root()
{noformat}
In the same time, if I slightly change the order of feature installation
(install activemq-client _before_ activemq), then the refresh doesn't happen:
{noformat}
karaf@root() feature:install -v -t cxf-ws-policy
Adding features: cxf-ws-policy/[3.1.1,3.1.1]
No deployment change.
karaf@root()
{noformat}
Note regarding AMQ vesrion - I'm using 5.11-SNAPSHOT because of a fix for
another bundle refresh problem: https://issues.apache.org/jira/browse/AMQ-5821
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work started] (KARAF-3889) The clusterName for the elasticsearch appender isn't an optional configuration as it should be.
[ https://issues.apache.org/jira/browse/KARAF-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KARAF-3889 started by Achim Nierbeck. - The clusterName for the elasticsearch appender isn't an optional configuration as it should be. Key: KARAF-3889 URL: https://issues.apache.org/jira/browse/KARAF-3889 Project: Karaf Issue Type: Bug Components: decanter Reporter: Achim Nierbeck Assignee: Achim Nierbeck Fix For: decanter-1.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KARAF-3889) The clusterName for the elasticsearch appender isn't an optional configuration as it should be.
[ https://issues.apache.org/jira/browse/KARAF-3889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Achim Nierbeck resolved KARAF-3889. --- Resolution: Fixed http://git-wip-us.apache.org/repos/asf/karaf-decanter/commit/71b248bc The clusterName for the elasticsearch appender isn't an optional configuration as it should be. Key: KARAF-3889 URL: https://issues.apache.org/jira/browse/KARAF-3889 Project: Karaf Issue Type: Bug Components: decanter Reporter: Achim Nierbeck Assignee: Achim Nierbeck Fix For: decanter-1.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (KARAF-3873) TimeoutTask doesn't correctly remove pending commands
[
https://issues.apache.org/jira/browse/KARAF-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KARAF-3873 started by Jean-Baptiste Onofré.
---
TimeoutTask doesn't correctly remove pending commands
-
Key: KARAF-3873
URL: https://issues.apache.org/jira/browse/KARAF-3873
Project: Karaf
Issue Type: Bug
Components: cellar-core
Affects Versions: cellar-4.0.0.M1, cellar-3.0.3, cellar-2.3.6
Reporter: Joe Hammerbacher
Assignee: Jean-Baptiste Onofré
{{TimeoutTask}} uses the following code to attempt to remove pending commands
after the timeout period has expired:
{noformat}
Boolean pending = store.getPending().containsKey(command);
if (pending) {
store.getPending().remove(command);
}
{noformat}
However, the keys for the {{ConcurrentMap}} returned by {{getPending()}} are
of type {{String}}, not {{Command}}. As a result, {{pending}} is always
{{false}} (and even if it were {{true}}, {{remove}} would fail to do
anything).
The intended functionality is likely:
{noformat}
Boolean pending = store.getPending().containsKey(command.getId());
if (pending) {
store.getPending().remove(command.getId());
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (KARAF-3873) TimeoutTask doesn't correctly remove pending commands
[
https://issues.apache.org/jira/browse/KARAF-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-3873:
Affects Version/s: (was: 4.0.0)
cellar-4.0.0.M1
cellar-2.3.6
TimeoutTask doesn't correctly remove pending commands
-
Key: KARAF-3873
URL: https://issues.apache.org/jira/browse/KARAF-3873
Project: Karaf
Issue Type: Bug
Components: cellar-core
Affects Versions: cellar-4.0.0.M1, cellar-3.0.3, cellar-2.3.6
Reporter: Joe Hammerbacher
{{TimeoutTask}} uses the following code to attempt to remove pending commands
after the timeout period has expired:
{noformat}
Boolean pending = store.getPending().containsKey(command);
if (pending) {
store.getPending().remove(command);
}
{noformat}
However, the keys for the {{ConcurrentMap}} returned by {{getPending()}} are
of type {{String}}, not {{Command}}. As a result, {{pending}} is always
{{false}} (and even if it were {{true}}, {{remove}} would fail to do
anything).
The intended functionality is likely:
{noformat}
Boolean pending = store.getPending().containsKey(command.getId());
if (pending) {
store.getPending().remove(command.getId());
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (KARAF-3873) TimeoutTask doesn't correctly remove pending commands
[
https://issues.apache.org/jira/browse/KARAF-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré reassigned KARAF-3873:
---
Assignee: Jean-Baptiste Onofré
TimeoutTask doesn't correctly remove pending commands
-
Key: KARAF-3873
URL: https://issues.apache.org/jira/browse/KARAF-3873
Project: Karaf
Issue Type: Bug
Components: cellar-core
Affects Versions: cellar-4.0.0.M1, cellar-3.0.3, cellar-2.3.6
Reporter: Joe Hammerbacher
Assignee: Jean-Baptiste Onofré
{{TimeoutTask}} uses the following code to attempt to remove pending commands
after the timeout period has expired:
{noformat}
Boolean pending = store.getPending().containsKey(command);
if (pending) {
store.getPending().remove(command);
}
{noformat}
However, the keys for the {{ConcurrentMap}} returned by {{getPending()}} are
of type {{String}}, not {{Command}}. As a result, {{pending}} is always
{{false}} (and even if it were {{true}}, {{remove}} would fail to do
anything).
The intended functionality is likely:
{noformat}
Boolean pending = store.getPending().containsKey(command.getId());
if (pending) {
store.getPending().remove(command.getId());
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (KARAF-3890) Provide Decanter CXF interceptor collector
Jean-Baptiste Onofré created KARAF-3890: --- Summary: Provide Decanter CXF interceptor collector Key: KARAF-3890 URL: https://issues.apache.org/jira/browse/KARAF-3890 Project: Karaf Issue Type: New Feature Components: decanter Reporter: Jean-Baptiste Onofré In order to monitor and log CXF usage, it would be great to provide a ready to use CXF interceptor that send an EventAdmin Event with CXF message details (a bit like the Decanter Camel Tracer Collector). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-3885) Memory leak when use interactive client shell
Freeman Fang created KARAF-3885: --- Summary: Memory leak when use interactive client shell Key: KARAF-3885 URL: https://issues.apache.org/jira/browse/KARAF-3885 Project: Karaf Issue Type: Bug Reporter: Freeman Fang I can see the object number of org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader keep increasing when I use client shell in interactive mode Even the client logout, the object created per each login never like org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader never get released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KARAF-3886) should escape specify characters in ROLE names
[ https://issues.apache.org/jira/browse/KARAF-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned KARAF-3886: --- Assignee: Freeman Fang should escape specify characters in ROLE names -- Key: KARAF-3886 URL: https://issues.apache.org/jira/browse/KARAF-3886 Project: Karaf Issue Type: Bug Components: karaf-security Reporter: Freeman Fang Assignee: Freeman Fang With RBAC for the OSGi service, we build the OSGi service filter which would has the ROLE names, so the special characters in ROLE(like () etc which is used popularly in LDAP group) name should be escaped, as if those special characters are invalid for the OSGi service filter(which follow the LDAP filter rule) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (KARAF-3885) Memory leak when use interactive client shell
[ https://issues.apache.org/jira/browse/KARAF-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned KARAF-3885: --- Assignee: Freeman Fang Memory leak when use interactive client shell - Key: KARAF-3885 URL: https://issues.apache.org/jira/browse/KARAF-3885 Project: Karaf Issue Type: Bug Reporter: Freeman Fang Assignee: Freeman Fang I can see the object number of org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader keep increasing when I use client shell in interactive mode Even the client logout, the object created per each login never like org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader never get released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (KARAF-3885) Memory leak when use interactive client shell
[ https://issues.apache.org/jira/browse/KARAF-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14642425#comment-14642425 ] Freeman Fang commented on KARAF-3885: - This happen with interactive mode only(if the client using exec mode then no leak), and also happen with sshd 0.14 Memory leak when use interactive client shell - Key: KARAF-3885 URL: https://issues.apache.org/jira/browse/KARAF-3885 Project: Karaf Issue Type: Bug Reporter: Freeman Fang Assignee: Freeman Fang I can see the object number of org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader keep increasing when I use client shell in interactive mode Even the client logout, the object created per each login never like org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader never get released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (KARAF-3885) Memory leak when use interactive client shell
[ https://issues.apache.org/jira/browse/KARAF-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KARAF-3885 started by Freeman Fang. --- Memory leak when use interactive client shell - Key: KARAF-3885 URL: https://issues.apache.org/jira/browse/KARAF-3885 Project: Karaf Issue Type: Bug Reporter: Freeman Fang Assignee: Freeman Fang I can see the object number of org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader keep increasing when I use client shell in interactive mode Even the client logout, the object created per each login never like org.apache.sshd.server.session.ServerSession jline.console.ConsoleReader never get released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (KARAF-3886) should escape specify characters in ROLE names
Freeman Fang created KARAF-3886: --- Summary: should escape specify characters in ROLE names Key: KARAF-3886 URL: https://issues.apache.org/jira/browse/KARAF-3886 Project: Karaf Issue Type: Bug Components: karaf-security Reporter: Freeman Fang With RBAC for the OSGi service, we build the OSGi service filter which would has the ROLE names, so the special characters in ROLE(like () etc which is used popularly in LDAP group) name should be escaped, as if those special characters are invalid for the OSGi service filter(which follow the LDAP filter rule) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (KARAF-3886) should escape specify characters in ROLE names
[ https://issues.apache.org/jira/browse/KARAF-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated KARAF-3886: Description: With RBAC for the OSGi service, we build the OSGi service filter which would has the ROLE names, so the special characters in ROLE(like () etc which is used popularly in LDAP group) name should be escaped, as those special characters are invalid for the OSGi service filter(which follow the LDAP filter rule) (was: With RBAC for the OSGi service, we build the OSGi service filter which would has the ROLE names, so the special characters in ROLE(like () etc which is used popularly in LDAP group) name should be escaped, as if those special characters are invalid for the OSGi service filter(which follow the LDAP filter rule)) should escape specify characters in ROLE names -- Key: KARAF-3886 URL: https://issues.apache.org/jira/browse/KARAF-3886 Project: Karaf Issue Type: Bug Components: karaf-security Reporter: Freeman Fang Assignee: Freeman Fang With RBAC for the OSGi service, we build the OSGi service filter which would has the ROLE names, so the special characters in ROLE(like () etc which is used popularly in LDAP group) name should be escaped, as those special characters are invalid for the OSGi service filter(which follow the LDAP filter rule) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (KARAF-3886) should escape specify characters in ROLE names
[ https://issues.apache.org/jira/browse/KARAF-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved KARAF-3886. - Resolution: Fixed Fix Version/s: 2.4.4 4.0.1 3.0.5 commit fix http://git-wip-us.apache.org/repos/asf/karaf/commit/33439779 for karaf-2.x branch http://git-wip-us.apache.org/repos/asf/karaf/commit/50690aaf for karaf-3.0.x branch http://git-wip-us.apache.org/repos/asf/karaf/commit/0cad2acc for master should escape specify characters in ROLE names -- Key: KARAF-3886 URL: https://issues.apache.org/jira/browse/KARAF-3886 Project: Karaf Issue Type: Bug Components: karaf-security Reporter: Freeman Fang Assignee: Freeman Fang Fix For: 3.0.5, 4.0.1, 2.4.4 With RBAC for the OSGi service, we build the OSGi service filter which would has the ROLE names, so the special characters in ROLE(like () etc which is used popularly in LDAP group) name should be escaped, as those special characters are invalid for the OSGi service filter(which follow the LDAP filter rule) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
