[jira] [Commented] (ARTEMIS-1187) Incompatible version when recreating a session with older server
[
https://issues.apache.org/jira/browse/ARTEMIS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032254#comment-16032254
]
ASF subversion and git services commented on ARTEMIS-1187:
--
Commit 6314b17667305188e29d64b9e8a8c382828662e6 in activemq-artemis's branch
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=6314b17 ]
ARTEMIS-1187 fix checkstyle
> Incompatible version when recreating a session with older server
>
>
> Key: ARTEMIS-1187
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1187
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> 1.5.x client is able to connect to 1.1.x server. However, when server is
> reloaded following error occurs:
> {noformat}
> 11:42:29,400 Thread-0 (ActiveMQ-client-global-threads-1319762469) ERROR
> [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl:993]
> AMQ214003: Failed to handle failover
>
> ActiveMQIncompatibleClientServerException[errorType=INCOMPATIBLE_CLIENT_SERVER_VERSIONS
> message=AMQ119033: Server and client versions incompatible]
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:407)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.recreateSession(ActiveMQSessionContext.java:637)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:958)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:771)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This works correctly with 1.5 server and old 1.1 client.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1197) Missing browse permission on Karaf
[ https://issues.apache.org/jira/browse/ARTEMIS-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031413#comment-16031413 ] ASF subversion and git services commented on ARTEMIS-1197: -- Commit 71fc3a8bb5e6d0da4a1ba889a6c7e62e7143a60f in activemq-artemis's branch refs/heads/master from [~gnt] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=71fc3a8 ] [ARTEMIS-1197] Add missing role to default OSGi configuration > Missing browse permission on Karaf > -- > > Key: ARTEMIS-1197 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1197 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1197) Missing browse permission on Karaf
[ https://issues.apache.org/jira/browse/ARTEMIS-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031415#comment-16031415 ] ASF GitHub Bot commented on ARTEMIS-1197: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1308 > Missing browse permission on Karaf > -- > > Key: ARTEMIS-1197 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1197 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1186) Consumer.receive hangs if http acceptor with non-zero batch-delay is configured
[
https://issues.apache.org/jira/browse/ARTEMIS-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031389#comment-16031389
]
ASF GitHub Bot commented on ARTEMIS-1186:
-
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1309
@TomasHofman please close this. already merged with a rebase.
> Consumer.receive hangs if http acceptor with non-zero batch-delay is
> configured
> ---
>
> Key: ARTEMIS-1186
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1186
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> Test scenario:
> # Call consumer.receive(1000) on empty queue.
> # Check whether receive call is unblocked after the 1 second.
> Issue: The receive call is not unblocked.
> I hit the issue which was initially reported in JBEAP-6443. I found out that
> the issue is somehow related to http connectors/acceptors and {{batch-delay}}
> parameter. I am able to reproduce it only if a client connects via
> http-connector with non-zero batch-delay. When I tried classic
> {{remote-connector}}, everything worked with both zero and non-zero
> {{batch-delay}}.
> I am able to reproduce the issue with both Artemis 1.1 (EAP 7.0.3) and
> Artemis 1.4.
> From the thread dump, you can see where the client hangs.
> {code}
> Stack trace of thread: Thread[Thread-10,5,main]
> ---java.lang.Object.wait(Native Method)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:258)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:391)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:198)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:122)
> ---org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:140)
> ---org.jboss.qa.hornetq.apps.clients.ReceiverAutoAck.run(ReceiverAutoAck.java:75)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1187) Incompatible version when recreating a session with older server
[
https://issues.apache.org/jira/browse/ARTEMIS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031386#comment-16031386
]
ASF subversion and git services commented on ARTEMIS-1187:
--
Commit 8eb5ce9ebd67d2fe623fc42e9647e392d2dfdccc in activemq-artemis's branch
refs/heads/master from [~thofman]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=8eb5ce9 ]
ARTEMIS-1187 Incompatible version when recreating a session with older server
> Incompatible version when recreating a session with older server
>
>
> Key: ARTEMIS-1187
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1187
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> 1.5.x client is able to connect to 1.1.x server. However, when server is
> reloaded following error occurs:
> {noformat}
> 11:42:29,400 Thread-0 (ActiveMQ-client-global-threads-1319762469) ERROR
> [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl:993]
> AMQ214003: Failed to handle failover
>
> ActiveMQIncompatibleClientServerException[errorType=INCOMPATIBLE_CLIENT_SERVER_VERSIONS
> message=AMQ119033: Server and client versions incompatible]
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:407)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.recreateSession(ActiveMQSessionContext.java:637)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:958)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:771)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This works correctly with 1.5 server and old 1.1 client.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1187) Incompatible version when recreating a session with older server
[
https://issues.apache.org/jira/browse/ARTEMIS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031388#comment-16031388
]
ASF GitHub Bot commented on ARTEMIS-1187:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1298
> Incompatible version when recreating a session with older server
>
>
> Key: ARTEMIS-1187
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1187
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> 1.5.x client is able to connect to 1.1.x server. However, when server is
> reloaded following error occurs:
> {noformat}
> 11:42:29,400 Thread-0 (ActiveMQ-client-global-threads-1319762469) ERROR
> [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl:993]
> AMQ214003: Failed to handle failover
>
> ActiveMQIncompatibleClientServerException[errorType=INCOMPATIBLE_CLIENT_SERVER_VERSIONS
> message=AMQ119033: Server and client versions incompatible]
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:407)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.recreateSession(ActiveMQSessionContext.java:637)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:958)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:771)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This works correctly with 1.5 server and old 1.1 client.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1187) Incompatible version when recreating a session with older server
[
https://issues.apache.org/jira/browse/ARTEMIS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031385#comment-16031385
]
ASF GitHub Bot commented on ARTEMIS-1187:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1298#discussion_r119394970
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ActiveMQSessionContext.java
---
@@ -686,7 +686,7 @@ protected CreateSessionMessage newCreateSession(String
username,
boolean autoCommitSends,
boolean autoCommitAcks,
boolean preAcknowledge)
{
- return new CreateSessionMessage(name, sessionChannel.getID(),
VersionLoader.getVersion().getIncrementingVersion(), username, password,
minLargeMessageSize, xa, autoCommitSends, autoCommitAcks, preAcknowledge,
confirmationWindow, null);
+ return new CreateSessionMessage(name, sessionChannel.getID(),
serverVersion, username, password, minLargeMessageSize, xa, autoCommitSends,
autoCommitAcks, preAcknowledge, confirmationWindow, null);
--- End diff --
Ohhh.. I see.. you're right!
merging it.. sorry for the hassle.. just wanted to make sure what was going
on.
> Incompatible version when recreating a session with older server
>
>
> Key: ARTEMIS-1187
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1187
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> 1.5.x client is able to connect to 1.1.x server. However, when server is
> reloaded following error occurs:
> {noformat}
> 11:42:29,400 Thread-0 (ActiveMQ-client-global-threads-1319762469) ERROR
> [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl:993]
> AMQ214003: Failed to handle failover
>
> ActiveMQIncompatibleClientServerException[errorType=INCOMPATIBLE_CLIENT_SERVER_VERSIONS
> message=AMQ119033: Server and client versions incompatible]
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:407)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.recreateSession(ActiveMQSessionContext.java:637)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:958)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:771)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This works correctly with 1.5 server and old 1.1 client.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1186) Consumer.receive hangs if http acceptor with non-zero batch-delay is configured
[
https://issues.apache.org/jira/browse/ARTEMIS-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031375#comment-16031375
]
ASF GitHub Bot commented on ARTEMIS-1186:
-
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/1309
Can you close this manually? or rebase your branch and push -f?
The commit ID changed as I merged with a rebase. This closes message
doesn't work on 1.x (just on master).
> Consumer.receive hangs if http acceptor with non-zero batch-delay is
> configured
> ---
>
> Key: ARTEMIS-1186
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1186
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> Test scenario:
> # Call consumer.receive(1000) on empty queue.
> # Check whether receive call is unblocked after the 1 second.
> Issue: The receive call is not unblocked.
> I hit the issue which was initially reported in JBEAP-6443. I found out that
> the issue is somehow related to http connectors/acceptors and {{batch-delay}}
> parameter. I am able to reproduce it only if a client connects via
> http-connector with non-zero batch-delay. When I tried classic
> {{remote-connector}}, everything worked with both zero and non-zero
> {{batch-delay}}.
> I am able to reproduce the issue with both Artemis 1.1 (EAP 7.0.3) and
> Artemis 1.4.
> From the thread dump, you can see where the client hangs.
> {code}
> Stack trace of thread: Thread[Thread-10,5,main]
> ---java.lang.Object.wait(Native Method)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:258)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:391)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:198)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:122)
> ---org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:140)
> ---org.jboss.qa.hornetq.apps.clients.ReceiverAutoAck.run(ReceiverAutoAck.java:75)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1186) Consumer.receive hangs if http acceptor with non-zero batch-delay is configured
[
https://issues.apache.org/jira/browse/ARTEMIS-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031374#comment-16031374
]
ASF subversion and git services commented on ARTEMIS-1186:
--
Commit bf814d486421425d651c8bf412a0e084ed0c09dd in activemq-artemis's branch
refs/heads/1.x from [~thofman]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=bf814d4 ]
ARTEMIS-1186 Consumer.receive hangs if http acceptor with non-zero batch-delay
is configured
> Consumer.receive hangs if http acceptor with non-zero batch-delay is
> configured
> ---
>
> Key: ARTEMIS-1186
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1186
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> Test scenario:
> # Call consumer.receive(1000) on empty queue.
> # Check whether receive call is unblocked after the 1 second.
> Issue: The receive call is not unblocked.
> I hit the issue which was initially reported in JBEAP-6443. I found out that
> the issue is somehow related to http connectors/acceptors and {{batch-delay}}
> parameter. I am able to reproduce it only if a client connects via
> http-connector with non-zero batch-delay. When I tried classic
> {{remote-connector}}, everything worked with both zero and non-zero
> {{batch-delay}}.
> I am able to reproduce the issue with both Artemis 1.1 (EAP 7.0.3) and
> Artemis 1.4.
> From the thread dump, you can see where the client hangs.
> {code}
> Stack trace of thread: Thread[Thread-10,5,main]
> ---java.lang.Object.wait(Native Method)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:258)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:391)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:198)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:122)
> ---org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:140)
> ---org.jboss.qa.hornetq.apps.clients.ReceiverAutoAck.run(ReceiverAutoAck.java:75)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1190) Long/int type mismatch in JDBCSequentialFile.setWritePosition
[
https://issues.apache.org/jira/browse/ARTEMIS-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031372#comment-16031372
]
ASF GitHub Bot commented on ARTEMIS-1190:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/1306
> Long/int type mismatch in JDBCSequentialFile.setWritePosition
> -
>
> Key: ARTEMIS-1190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1190
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
>
> In the {{JDBCSequentialFile.setWritePosition}} there is mismatch between
> types. The parameter of the method has type {{int}} but the private field has
> type {{long}}.
> {code:java}
> private long writePosition = 0;
> void setWritePosition(int writePosition) {
>this.writePosition = writePosition;
> }
> {code}
> Because of this in {{JDBCSequentialFileFactoryDriver.loadFile}} the long is
> unnecessarily retype to int.
> {code:java}
> public void loadFile(JDBCSequentialFile file) throws SQLException {
> synchronized (connection) {
>connection.setAutoCommit(false);
>readLargeObject.setLong(1, file.getId());
>try (ResultSet rs = readLargeObject.executeQuery()) {
> if (rs.next()) {
> Blob blob = rs.getBlob(1);
> if (blob != null) {
> file.setWritePosition((int) blob.length());
> } else {
> logger.warn("ERROR NO BLOB FOR FILE" + "File: " +
> file.getFileName() + " " + file.getId());
> }
> }
> connection.commit();
>} catch (SQLException e) {
> connection.rollback();
> throw e;
>}
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1190) Long/int type mismatch in JDBCSequentialFile.setWritePosition
[
https://issues.apache.org/jira/browse/ARTEMIS-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031371#comment-16031371
]
ASF subversion and git services commented on ARTEMIS-1190:
--
Commit dc795dc564eff29b58f4de5199168800476a9f88 in activemq-artemis's branch
refs/heads/1.x from [~eduda]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=dc795dc ]
ARTEMIS-1190 Long/int type mismatch in JDBCSequentialFile.setWritePosition
(cherry picked from commit 69740a987d580c994a287ba533ae34d1bad407f1)
> Long/int type mismatch in JDBCSequentialFile.setWritePosition
> -
>
> Key: ARTEMIS-1190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1190
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 1.5.5, 2.1.0
>Reporter: Erich Duda
>
> In the {{JDBCSequentialFile.setWritePosition}} there is mismatch between
> types. The parameter of the method has type {{int}} but the private field has
> type {{long}}.
> {code:java}
> private long writePosition = 0;
> void setWritePosition(int writePosition) {
>this.writePosition = writePosition;
> }
> {code}
> Because of this in {{JDBCSequentialFileFactoryDriver.loadFile}} the long is
> unnecessarily retype to int.
> {code:java}
> public void loadFile(JDBCSequentialFile file) throws SQLException {
> synchronized (connection) {
>connection.setAutoCommit(false);
>readLargeObject.setLong(1, file.getId());
>try (ResultSet rs = readLargeObject.executeQuery()) {
> if (rs.next()) {
> Blob blob = rs.getBlob(1);
> if (blob != null) {
> file.setWritePosition((int) blob.length());
> } else {
> logger.warn("ERROR NO BLOB FOR FILE" + "File: " +
> file.getFileName() + " " + file.getId());
> }
> }
> connection.commit();
>} catch (SQLException e) {
> connection.rollback();
> throw e;
>}
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1185) Inter-Process Journal Sampler Profiler + CLI command
[ https://issues.apache.org/jira/browse/ARTEMIS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031353#comment-16031353 ] ASF GitHub Bot commented on ARTEMIS-1185: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1295 @franz1981 I was just looking from the POV of the code.. TimedBuffer->profiler (whatever the name is) is instantiating an output file. shouldn't it be configurable for the running server? the CLI to read it could also get the file from the configuration if you're running from the instance. > Inter-Process Journal Sampler Profiler + CLI command > > > Key: ARTEMIS-1185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1185 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > It provides a sampling profiler on buffered ASYNCIO/NIO based journals. > The profiling has a minimal cost in term of CPU time for each sample (the > dominant costs are System.nanoTime() and a single cache line invalidation) > and total memory footprint (~OS page size in bytes). > A proper CLI command activates a sampler to collect (ie CSV) the profiled > data, showing the precision of the sampling: data loss is not considered a > failure condition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[
https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031332#comment-16031332
]
ASF GitHub Bot commented on ARTEMIS-1196:
-
Github user gnodet commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1307#discussion_r119387203
--- Diff: artemis-features/src/main/resources/features.xml ---
@@ -54,8 +54,8 @@
mvn:org.jboss.logging/jboss-logging/${jboss.logging.version}
mvn:org.jgroups/jgroups/${jgroups.version}
- mvn:org.apache.geronimo.specs/geronimo-json_1.0_spec/${json-p.spec.version}
- mvn:org.apache.johnzon/johnzon-core/${johnzon.version}
+ mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.json-api-1.1/2.8-SNAPSHOT
--- End diff --
Yeah, that's why I said it's not to be committed.
Once there is a release of the spec, I'll update the PR.
> Unusable JSON api on Karaf
> --
>
> Key: ARTEMIS-1196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1196
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[
https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031290#comment-16031290
]
ASF GitHub Bot commented on ARTEMIS-1196:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1307#discussion_r119383359
--- Diff: artemis-features/src/main/resources/features.xml ---
@@ -54,8 +54,8 @@
mvn:org.jboss.logging/jboss-logging/${jboss.logging.version}
mvn:org.jgroups/jgroups/${jgroups.version}
- mvn:org.apache.geronimo.specs/geronimo-json_1.0_spec/${json-p.spec.version}
- mvn:org.apache.johnzon/johnzon-core/${johnzon.version}
+ mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.json-api-1.1/2.8-SNAPSHOT
--- End diff --
ok, but I don't like snapshot dependencies on main.. 1 year from now we
won't be able to compile the code when the snapshot is gone.. and if I ever go
back to this tag.
> Unusable JSON api on Karaf
> --
>
> Key: ARTEMIS-1196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1196
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[
https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031280#comment-16031280
]
ASF GitHub Bot commented on ARTEMIS-1196:
-
Github user gnodet commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1307#discussion_r119382149
--- Diff: artemis-features/src/main/resources/features.xml ---
@@ -54,8 +54,8 @@
mvn:org.jboss.logging/jboss-logging/${jboss.logging.version}
mvn:org.jgroups/jgroups/${jgroups.version}
- mvn:org.apache.geronimo.specs/geronimo-json_1.0_spec/${json-p.spec.version}
- mvn:org.apache.johnzon/johnzon-core/${johnzon.version}
+ mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.json-api-1.1/2.8-SNAPSHOT
--- End diff --
In karaf, we usually use the servicemix specs versions. They do work on
their own, while the geronimo ones need an additional bundle.
> Unusable JSON api on Karaf
> --
>
> Key: ARTEMIS-1196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1196
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[
https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031276#comment-16031276
]
ASF GitHub Bot commented on ARTEMIS-1196:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1307#discussion_r119380503
--- Diff: artemis-features/src/main/resources/features.xml ---
@@ -54,8 +54,8 @@
mvn:org.jboss.logging/jboss-logging/${jboss.logging.version}
mvn:org.jgroups/jgroups/${jgroups.version}
- mvn:org.apache.geronimo.specs/geronimo-json_1.0_spec/${json-p.spec.version}
- mvn:org.apache.johnzon/johnzon-core/${johnzon.version}
+ mvn:org.apache.servicemix.specs/org.apache.servicemix.specs.json-api-1.1/2.8-SNAPSHOT
--- End diff --
I can't merge this with a snapshot.. besides.. the right way would be to
update json-p.spec.version.
> Unusable JSON api on Karaf
> --
>
> Key: ARTEMIS-1196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1196
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1185) Inter-Process Journal Sampler Profiler + CLI command
[ https://issues.apache.org/jira/browse/ARTEMIS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031174#comment-16031174 ] ASF GitHub Bot commented on ARTEMIS-1185: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1295 @clebertsuconic But the *sampler* is not strictly part of Artemis code, is a CLI command that works as a separated process from the broker. The user can choose every time a different trace file without changing the broker configuration, on the fly, while the broker is running. > Inter-Process Journal Sampler Profiler + CLI command > > > Key: ARTEMIS-1185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1185 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > It provides a sampling profiler on buffered ASYNCIO/NIO based journals. > The profiling has a minimal cost in term of CPU time for each sample (the > dominant costs are System.nanoTime() and a single cache line invalidation) > and total memory footprint (~OS page size in bytes). > A proper CLI command activates a sampler to collect (ie CSV) the profiled > data, showing the precision of the sampling: data loss is not considered a > failure condition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1185) Inter-Process Journal Sampler Profiler + CLI command
[ https://issues.apache.org/jira/browse/ARTEMIS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031161#comment-16031161 ] ASF GitHub Bot commented on ARTEMIS-1185: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1295 ``Currently the user running the sampler could choose where put the trace recorded from the profiler using the --out parameter:`` There's an option on the configuration. I think it's logRates.. something like that... if you used the config for that, you won't have to configure the --out. > Inter-Process Journal Sampler Profiler + CLI command > > > Key: ARTEMIS-1185 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1185 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > > It provides a sampling profiler on buffered ASYNCIO/NIO based journals. > The profiling has a minimal cost in term of CPU time for each sample (the > dominant costs are System.nanoTime() and a single cache line invalidation) > and total memory footprint (~OS page size in bytes). > A proper CLI command activates a sampler to collect (ie CSV) the profiled > data, showing the precision of the sampling: data loss is not considered a > failure condition. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[
https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031136#comment-16031136
]
ASF GitHub Bot commented on ARTEMIS-1196:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1307#discussion_r119352351
--- Diff:
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/karaf/ArtemisFeatureTest.java
---
@@ -146,11 +155,26 @@ public Boolean call() throws Exception {
connection = factory.createConnection(USER, PASSWORD);
connection.start();
- javax.jms.Session sess = connection.createSession(false,
javax.jms.Session.AUTO_ACKNOWLEDGE);
+ QueueSession sess = (QueueSession)
connection.createSession(false, javax.jms.Session.AUTO_ACKNOWLEDGE);
Queue queue = sess.createQueue("exampleQueue");
MessageProducer producer = sess.createProducer(queue);
producer.send(sess.createTextMessage("TEST"));
+ // Test management
+ Queue managementQueue = sess.createQueue("activemq.management");
+ QueueRequestor requestor = new QueueRequestor(sess,
managementQueue);
+ connection.start();
+ TextMessage m = sess.createTextMessage();
+ m.setStringProperty("_AMQ_ResourceName", "broker");
+ m.setStringProperty("_AMQ_OperationName", "getQueueNames");
+ m.setText("[\"ANYCAST\"]");
+ Message reply = requestor.request(m);
+ String json = ((TextMessage) reply).getText();
+ JsonArray array = Json.createReader(new
StringReader(json)).readArray();
+ List queues = (List) array.get(0);
+ assertNotNull(queues);
+
System.out.println(queues.stream().map(JsonString::getString).collect(Collectors.joining(",
", "Queues: ", "")));
--- End diff --
If we could let's not add to the noise
> Unusable JSON api on Karaf
> --
>
> Key: ARTEMIS-1196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1196
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMQ-6589) Broker hangs by shutdown after loosing exclusive lock
[
https://issues.apache.org/jira/browse/AMQ-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031067#comment-16031067
]
Andrei Shakirin commented on AMQ-6589:
--
Thanks, will take the thread dump by next occurance
> Broker hangs by shutdown after loosing exclusive lock
> -
>
> Key: AMQ-6589
> URL: https://issues.apache.org/jira/browse/AMQ-6589
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.4
> Environment: Linux
>Reporter: Andrei Shakirin
> Attachments: activemq-old-master-anonymized.log, activemq.xml
>
>
> 1) Configuration: ActiveMQ brokers are configured with shared store (NFS) and
> shared file locker with configured lockAcquireSleepInterval:
> {code:xml}
>
>
>
>
>
>
>
>
>checkForCorruptJournalFiles="true" checksumJournalFiles="true" />
>
>
>
>
>
> {code}
> 2) Workflow
> The master broker looses exclusive lock and tries to shutdown, it is reported
> in the log file:
> {code}
> 2017-01-31 16:30:45,921 | INFO | Lock file /CE/activemq/lock, locked at Thu
> Jan 05 01:14:11 CET 2017, has been modified at Tue Jan 31 16:30:45 CET 2017 |
> org.apache.activemq.util.LockFile | ActiveMQ Lock KeepAlive Timer
> 2017-01-31 16:30:45,921 | ERROR | hostXXX, no longer able to keep the
> exclusive lock so giving up being a master |
> org.apache.activemq.broker.LockableServiceSupport | ActiveMQ Lock KeepAlive
> Timer
> 2017-01-31 16:30:45,924 | INFO | Apache ActiveMQ 5.13.4 (hostXXX,
> ID:xxx-36540-1483575278364-0:1) is shutting down |
> org.apache.activemq.broker.BrokerService | ActiveMQ Lock KeepAlive Timer
> {code}
> 3) Problem
> Broker hangs during shutdown, I see a lot of messages like:
> {code}
> The connection to 'tcp://xxx:55057' is taking a long time to shutdown.
> {code}
> The problem happens only in case of shutdown after loosing exclusive log,
> normal shutdown works fine.
> I see some other defects with this problem: AMQ-3435, AMQ-3293, AMQ-4073, but
> all of them have to be fixed in AMQ 5.13.4.
> What can be the reason of this problem?
> Note: the connections were created from "old" AMQ clients (5.7.0). Could the
> problem related with that?
> Complete log file and configuration are attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMQ-6589) Broker hangs by shutdown after loosing exclusive lock
[
https://issues.apache.org/jira/browse/AMQ-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031062#comment-16031062
]
Gary Tully commented on AMQ-6589:
-
Please attach a thread dump of the broker in this "cannot shutdown" state. It
should be possible to see what operations are pending on those connections that
are preventing the stop from completing.
> Broker hangs by shutdown after loosing exclusive lock
> -
>
> Key: AMQ-6589
> URL: https://issues.apache.org/jira/browse/AMQ-6589
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.4
> Environment: Linux
>Reporter: Andrei Shakirin
> Attachments: activemq-old-master-anonymized.log, activemq.xml
>
>
> 1) Configuration: ActiveMQ brokers are configured with shared store (NFS) and
> shared file locker with configured lockAcquireSleepInterval:
> {code:xml}
>
>
>
>
>
>
>
>
>checkForCorruptJournalFiles="true" checksumJournalFiles="true" />
>
>
>
>
>
> {code}
> 2) Workflow
> The master broker looses exclusive lock and tries to shutdown, it is reported
> in the log file:
> {code}
> 2017-01-31 16:30:45,921 | INFO | Lock file /CE/activemq/lock, locked at Thu
> Jan 05 01:14:11 CET 2017, has been modified at Tue Jan 31 16:30:45 CET 2017 |
> org.apache.activemq.util.LockFile | ActiveMQ Lock KeepAlive Timer
> 2017-01-31 16:30:45,921 | ERROR | hostXXX, no longer able to keep the
> exclusive lock so giving up being a master |
> org.apache.activemq.broker.LockableServiceSupport | ActiveMQ Lock KeepAlive
> Timer
> 2017-01-31 16:30:45,924 | INFO | Apache ActiveMQ 5.13.4 (hostXXX,
> ID:xxx-36540-1483575278364-0:1) is shutting down |
> org.apache.activemq.broker.BrokerService | ActiveMQ Lock KeepAlive Timer
> {code}
> 3) Problem
> Broker hangs during shutdown, I see a lot of messages like:
> {code}
> The connection to 'tcp://xxx:55057' is taking a long time to shutdown.
> {code}
> The problem happens only in case of shutdown after loosing exclusive log,
> normal shutdown works fine.
> I see some other defects with this problem: AMQ-3435, AMQ-3293, AMQ-4073, but
> all of them have to be fixed in AMQ 5.13.4.
> What can be the reason of this problem?
> Note: the connections were created from "old" AMQ clients (5.7.0). Could the
> problem related with that?
> Complete log file and configuration are attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[
https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031046#comment-16031046
]
ASF GitHub Bot commented on ARTEMIS-1196:
-
Github user gnodet commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1307#discussion_r119338658
--- Diff:
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/karaf/ArtemisFeatureTest.java
---
@@ -146,11 +155,26 @@ public Boolean call() throws Exception {
connection = factory.createConnection(USER, PASSWORD);
connection.start();
- javax.jms.Session sess = connection.createSession(false,
javax.jms.Session.AUTO_ACKNOWLEDGE);
+ QueueSession sess = (QueueSession)
connection.createSession(false, javax.jms.Session.AUTO_ACKNOWLEDGE);
Queue queue = sess.createQueue("exampleQueue");
MessageProducer producer = sess.createProducer(queue);
producer.send(sess.createTextMessage("TEST"));
+ // Test management
+ Queue managementQueue = sess.createQueue("activemq.management");
+ QueueRequestor requestor = new QueueRequestor(sess,
managementQueue);
+ connection.start();
+ TextMessage m = sess.createTextMessage();
+ m.setStringProperty("_AMQ_ResourceName", "broker");
+ m.setStringProperty("_AMQ_OperationName", "getQueueNames");
+ m.setText("[\"ANYCAST\"]");
+ Message reply = requestor.request(m);
+ String json = ((TextMessage) reply).getText();
+ JsonArray array = Json.createReader(new
StringReader(json)).readArray();
+ List queues = (List) array.get(0);
+ assertNotNull(queues);
+
System.out.println(queues.stream().map(JsonString::getString).collect(Collectors.joining(",
", "Queues: ", "")));
--- End diff --
The test already spits out lots of things to the console, so I'm happy to
remove that line if you want, though it's really burried in the whole test
output.
> Unusable JSON api on Karaf
> --
>
> Key: ARTEMIS-1196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1196
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMQ-6257) duplicate typeconverter in activemq-camel and activemq-osgi
[
https://issues.apache.org/jira/browse/AMQ-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated AMQ-6257:
-
Issue Type: Improvement (was: Bug)
> duplicate typeconverter in activemq-camel and activemq-osgi
> ---
>
> Key: AMQ-6257
> URL: https://issues.apache.org/jira/browse/AMQ-6257
> Project: ActiveMQ
> Issue Type: Improvement
> Components: activemq-camel
>Affects Versions: 5.12.1
>Reporter: Ton Swieb
>Priority: Minor
>
> Both activemq-camel and activemq-osgi export the package
> org.apache.activemq.camel.converter which gives overriding type converter
> warnings.
> {code}
> 07:42:13,303 | WARN | xtenderThread-14 | DefaultTypeConverter |
> 205 - org.apache.camel.camel-core - 2.16.1 | Overriding type converter from:
> StaticMethodTypeConverter: public static
> org.apache.activemq.command.ActiveMQDestination
> org.apache.activemq.camel.converter.ActiveMQConverter.toDestination(java.lang.String)
> to: StaticMethodTypeConverter: public static
> org.apache.activemq.command.ActiveMQDestination
> org.apache.activemq.camel.converter.ActiveMQConverter.toDestination(java.lang.String)
> 07:42:13,304 | WARN | xtenderThread-14 | DefaultTypeConverter |
> 205 - org.apache.camel.camel-core - 2.16.1 | Overriding type converter from:
> InstanceMethodTypeConverter: public org.apache.camel.Processor
> org.apache.activemq.camel.converter.ActiveMQMessageConverter.toProcessor(javax.jms.MessageListener)
> to: InstanceMethodTypeConverter: public org.apache.camel.Processor
> org.apache.activemq.camel.converter.ActiveMQMessageConverter.toProcessor(javax.jms.MessageListener)
> 07:42:13,304 | WARN | xtenderThread-14 | DefaultTypeConverter |
> 205 - org.apache.camel.camel-core - 2.16.1 | Overriding type converter from:
> InstanceMethodTypeConverter: public
> org.apache.activemq.command.ActiveMQMessage
> org.apache.activemq.camel.converter.ActiveMQMessageConverter.toMessage(org.apache.camel.Exchange)
> throws javax.jms.JMSException to: InstanceMethodTypeConverter: public
> org.apache.activemq.command.ActiveMQMessage
> org.apache.activemq.camel.converter.ActiveMQMessageConverter.toMessage(org.apache.camel.Exchange)
> throws javax.jms.JMSException
> {code}
> Both the activemq-camel and activemq-osgi bundle are installed when
> installing the feature activemq-camel. The activemq-camel feature has a
> dependency on the activemq-client feature which loads the activemq-osgi
> bundle.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (AMQ-4727) Unable to add camel routes to activemq running in a karaf container
[ https://issues.apache.org/jira/browse/AMQ-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved AMQ-4727. -- Resolution: Later Old ticket, create new ticket with newer versions of ActiveMQ if you can reproduce any kind of this > Unable to add camel routes to activemq running in a karaf container > --- > > Key: AMQ-4727 > URL: https://issues.apache.org/jira/browse/AMQ-4727 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-camel >Affects Versions: 5.8.0 > Environment: jboss-amq-6.0 on Red Hat Enterprise Linux Server release > 6.4 (Santiago) >Reporter: Noel O'Connor > Fix For: 5.9.0 > > > gtully: noconnor: there is a pax exam test on apache trunk that validates the > karaf features - see the xml > https://github.com/apache/activemq/blob/trunk/activemq-karaf-itest/src/test/resources/org/apache/activemq/karaf/itest/activemq-nd-camel.xml > [07:35am] gtully: in 6.0 u can try the same - just embed a context > [07:36am] gtully: so modify etc/activemq.xml > [07:36am] noconnor: gtully: thanks, trying it now > [07:44am] noconnor: gtully: same issue again, "bundle context must be > specified" > [07:49am] gtully: noconnor: i see the same thing with the test on trunk… need > to investigate that a bit…can u raise an amq issue > [07:51am] gtully: noconnor: on trunk that can be reproduced with mvn test > -Dtest=ActiveMQBrokerNdCamelFeatureTest in the activemq-karaf-itest module > Exception on start: org.springframework.beans.factory.BeanCreationException: > Error creating bean with name 'activemq' defined in file > [/opt/jboss-amq/jboss-a-mq-6.0.0.redhat-024 > /etc/activemq.xml]: Initialization of bean failed; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'camel': Invocation > of init method failed; nested exception is > java.lang.IllegalArgumentException: BundleContext must be specified > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'activemq' defined in file > [/opt/jboss-amq/jboss-a-mq-6.0.0.redhat-024/etc/activemq.xml]: I > nitialization of bean failed; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'camel': Invocation of init method failed > ; nested exception is java.lang.IllegalArgumentException: BundleContext must > be specified > Also I had to add the activemq-camel feature to org.apache.karaf.features.cfg > to get the namespaces resolved -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMQ-6692) Broker hangs after file writting exception
[
https://issues.apache.org/jira/browse/AMQ-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Shakirin updated AMQ-6692:
-
Description:
I observe the following strange broker behavior:
after following error by creating queue directory:
{code}
2017-05-29 10:15:25,477 | ERROR | java.lang.RuntimeException: Failed to start
per destination persistence adapter for destination: queue://MY.QUEUE,
options:[KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.SPLIT],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.CREATE],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.UPDATE],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fMY.QUEUE]] |
org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter | ActiveMQ
Transport: tcp:///172.26.244.182:54858@61617
java.io.IOException: Failed to create directory
'/CE/activemq/queue#3a#2f#2fMY.QUEUE'
at
org.apache.activemq.util.IOHelper.mkdirs(IOHelper.java:331)[activemq-broker-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:442)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:287)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:215)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)[activemq-client-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:223)[activemq-kahadb-store-5.13.4.jar:5.13.4]
{code}
The broker hangs and keeps running connections. The JMS clients are blocked for
undefined time.
InactivityMonitor reports a bunch of following warnings:
{code}
2017-05-29 11:31:09,545 | WARN | Transport Connection to:
tcp://172.26.244.182:37994 failed: java.net.SocketException: Broken pipe (Write
failed) | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ
InactivityMonitor Worker
{code}
Any option to prevent blocking benavior and drop active connections?
was:
I observe the following strange broker behavior:
after following error by creating queue directory:
{code}
2017-05-29 10:15:25,477 | ERROR | java.lang.RuntimeException: Failed to start
per destination persistence adapter for destination: queue://MY.QUEUE,
options:[KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.SPLIT],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.CREATE],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.UPDATE],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fMY.QUEUE]] |
org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter | ActiveMQ
Transport: tcp:///172.26.244.182:54858@61617
java.io.IOException: Failed to create directory
'/CE/activemq/queue#3a#2f#2fMY.QUEUE'
at
org.apache.activemq.util.IOHelper.mkdirs(IOHelper.java:331)[activemq-broker-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:442)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:287)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:215)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)[activemq-client-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:223)[activemq-kahadb-store-5.13.4.jar:5.13.4]
{code}
The broker hangs and keeps running connections. The JMS clients are blocked for
undfined time.
InactivityMonitor reports a bunch of following warnings:
{code}
2017-05-29 11:31:09,545 | WARN | Transport Connection to:
tcp://172.26.244.182:37994 failed: java.net.SocketException: Broken pipe (Write
failed) | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ
InactivityMonitor Worker
{code}
Any option to prevent blocking benavior and drop active connections?
> Broker hangs after file writting exception
> --
>
> Key: AMQ-6692
> URL: https://issues.apache.org/jira/browse/AMQ-6692
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.4
>Reporter: Andrei Shakirin
>
> I observe the following strange broker behavior:
> after following error by creating queue directory:
> {code}
> 2017-05-29 10:15:25,477 | ERROR | java.lang.RuntimeException: Failed to start
> per destination persistence adapter for destination: queue://MY.QUEUE,
> options:[KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.SPLIT],
> KahaDBPersistence
[jira] [Updated] (AMQ-6692) Broker hangs after file writting exception
[
https://issues.apache.org/jira/browse/AMQ-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Shakirin updated AMQ-6692:
-
Description:
I observe the following strange broker behavior:
after following error by creating queue directory:
{code}
2017-05-29 10:15:25,477 | ERROR | java.lang.RuntimeException: Failed to start
per destination persistence adapter for destination: queue://MY.QUEUE,
options:[KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.SPLIT],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.CREATE],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.UPDATE],
KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fMY.QUEUE]] |
org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter | ActiveMQ
Transport: tcp:///172.26.244.182:54858@61617
java.io.IOException: Failed to create directory
'/CE/activemq/queue#3a#2f#2fMY.QUEUE'
at
org.apache.activemq.util.IOHelper.mkdirs(IOHelper.java:331)[activemq-broker-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:442)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:287)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:215)[activemq-kahadb-store-5.13.4.jar:5.13.4]
at
org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)[activemq-client-5.13.4.jar:5.13.4]
at
org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:223)[activemq-kahadb-store-5.13.4.jar:5.13.4]
{code}
The broker hangs and keeps running connections. The JMS clients are blocked for
undfined time.
InactivityMonitor reports a bunch of following warnings:
{code}
2017-05-29 11:31:09,545 | WARN | Transport Connection to:
tcp://172.26.244.182:37994 failed: java.net.SocketException: Broken pipe (Write
failed) | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ
InactivityMonitor Worker
{code}
Any option to prevent blocking benavior and drop active connections?
> Broker hangs after file writting exception
> --
>
> Key: AMQ-6692
> URL: https://issues.apache.org/jira/browse/AMQ-6692
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.4
>Reporter: Andrei Shakirin
>
> I observe the following strange broker behavior:
> after following error by creating queue directory:
> {code}
> 2017-05-29 10:15:25,477 | ERROR | java.lang.RuntimeException: Failed to start
> per destination persistence adapter for destination: queue://MY.QUEUE,
> options:[KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.SPLIT],
> KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.CREATE],
> KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fQ.MP.ORDER.UPDATE],
> KahaDBPersistenceAdapter[/CE/activemq/queue#3a#2f#2fMY.QUEUE]] |
> org.apache.activemq.store.kahadb.MultiKahaDBPersistenceAdapter | ActiveMQ
> Transport: tcp:///172.26.244.182:54858@61617
> java.io.IOException: Failed to create directory
> '/CE/activemq/queue#3a#2f#2fMY.QUEUE'
> at
> org.apache.activemq.util.IOHelper.mkdirs(IOHelper.java:331)[activemq-broker-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.load(MessageDatabase.java:442)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.doStart(MessageDatabase.java:287)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.KahaDBStore.doStart(KahaDBStore.java:215)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.util.ServiceSupport.start(ServiceSupport.java:55)[activemq-client-5.13.4.jar:5.13.4]
> at
> org.apache.activemq.store.kahadb.KahaDBPersistenceAdapter.doStart(KahaDBPersistenceAdapter.java:223)[activemq-kahadb-store-5.13.4.jar:5.13.4]
> {code}
> The broker hangs and keeps running connections. The JMS clients are blocked
> for undfined time.
> InactivityMonitor reports a bunch of following warnings:
> {code}
> 2017-05-29 11:31:09,545 | WARN | Transport Connection to:
> tcp://172.26.244.182:37994 failed: java.net.SocketException: Broken pipe
> (Write failed) | org.apache.activemq.broker.TransportConnection.Transport |
> ActiveMQ InactivityMonitor Worker
> {code}
> Any option to prevent blocking benavior and drop active connections?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (AMQ-6570) activemq-camel needs explicit javax.jms import to work with JMS 2.0
[ https://issues.apache.org/jira/browse/AMQ-6570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated AMQ-6570: - Issue Type: Improvement (was: Bug) > activemq-camel needs explicit javax.jms import to work with JMS 2.0 > --- > > Key: AMQ-6570 > URL: https://issues.apache.org/jira/browse/AMQ-6570 > Project: ActiveMQ > Issue Type: Improvement > Components: activemq-camel >Affects Versions: 5.14.3 >Reporter: Matt Pavlovich > > The activemq-camel component needs the explicit javax.jms;version="[1.1,3)" > import line to work with JMS 2.0 API libs in an OSGi runtime -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (AMQ-6230) Camel 2.17.0 breaks Karaf integration tests
[ https://issues.apache.org/jira/browse/AMQ-6230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned AMQ-6230: Assignee: (was: Claus Ibsen) > Camel 2.17.0 breaks Karaf integration tests > --- > > Key: AMQ-6230 > URL: https://issues.apache.org/jira/browse/AMQ-6230 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-camel >Affects Versions: 5.13.2 >Reporter: Christopher L. Shannon > Fix For: 5.15.0 > > > The new Camel version seems to cause the ActiveMQBrokerNdCamelFeatureTest > test to fail. > https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Java8/lastBuild/org.apache.activemq$activemq-karaf-itest/testReport/org.apache.activemq.karaf.itest/ActiveMQBrokerNdCamelFeatureTest/test/ > It looks like a bunch of work was done with Karaf and to get rid of Spring DM > in the new version which is probably the issue as ActiveMQ still has the > Spring DM stuff laying around. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (AMQ-4727) Unable to add camel routes to activemq running in a karaf container
[ https://issues.apache.org/jira/browse/AMQ-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned AMQ-4727: Assignee: (was: Jean-Baptiste Onofré) > Unable to add camel routes to activemq running in a karaf container > --- > > Key: AMQ-4727 > URL: https://issues.apache.org/jira/browse/AMQ-4727 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-camel >Affects Versions: 5.8.0 > Environment: jboss-amq-6.0 on Red Hat Enterprise Linux Server release > 6.4 (Santiago) >Reporter: Noel O'Connor > Fix For: 5.9.0 > > > gtully: noconnor: there is a pax exam test on apache trunk that validates the > karaf features - see the xml > https://github.com/apache/activemq/blob/trunk/activemq-karaf-itest/src/test/resources/org/apache/activemq/karaf/itest/activemq-nd-camel.xml > [07:35am] gtully: in 6.0 u can try the same - just embed a context > [07:36am] gtully: so modify etc/activemq.xml > [07:36am] noconnor: gtully: thanks, trying it now > [07:44am] noconnor: gtully: same issue again, "bundle context must be > specified" > [07:49am] gtully: noconnor: i see the same thing with the test on trunk… need > to investigate that a bit…can u raise an amq issue > [07:51am] gtully: noconnor: on trunk that can be reproduced with mvn test > -Dtest=ActiveMQBrokerNdCamelFeatureTest in the activemq-karaf-itest module > Exception on start: org.springframework.beans.factory.BeanCreationException: > Error creating bean with name 'activemq' defined in file > [/opt/jboss-amq/jboss-a-mq-6.0.0.redhat-024 > /etc/activemq.xml]: Initialization of bean failed; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'camel': Invocation > of init method failed; nested exception is > java.lang.IllegalArgumentException: BundleContext must be specified > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'activemq' defined in file > [/opt/jboss-amq/jboss-a-mq-6.0.0.redhat-024/etc/activemq.xml]: I > nitialization of bean failed; nested exception is > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'camel': Invocation of init method failed > ; nested exception is java.lang.IllegalArgumentException: BundleContext must > be specified > Also I had to add the activemq-camel feature to org.apache.karaf.features.cfg > to get the namespaces resolved -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (AMQ-6457) Durable Subscribers going offline - Over Network Of Brokers - Duplex Connection
[
https://issues.apache.org/jira/browse/AMQ-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated AMQ-6457:
-
Component/s: (was: activemq-camel)
> Durable Subscribers going offline - Over Network Of Brokers - Duplex
> Connection
> ---
>
> Key: AMQ-6457
> URL: https://issues.apache.org/jira/browse/AMQ-6457
> Project: ActiveMQ
> Issue Type: Bug
> Components: networkbridge
>Affects Versions: 5.13.3, 5.14.0
> Environment: Active MQ Version 5.13.3
> Karaf 4.0.6
> Camel 2.16.3
> -Active MQ brokers are deployed in Karaf container.
> -Cluster of Active MQ Brokers (Network of brokers, configured as HUB and
> SPOKES).
> -Broker(s) at Hub (Master/Slave configuration using Shared File System)
> - Broker(s) at spoke(s)- Connected to HUB using Duplex Network Connector (
> Openwire/NIO)
>Reporter: Ranjit Nethi
>
> -Active MQ brokers are deployed in Karaf container.
> -Cluster of Active MQ Brokers (Network of brokers, configured as HUB and
> SPOKES).
> -Broker(s) at Hub (Master/Slave configuration using Shared File System)
> - Broker(s) at spoke(s)- Connected to HUB using Duplex Network Connector (
> Openwire/NIO), one for topic and one for queue
> Issue: We have durable subscriptions to topics on HUB and producers on
> Spokes. We are aware of network outages between the HUB and SPOKE brokers,
> sometimes we are experiencing multiple outages and as a result we see the
> topic subscribers end up as offline and continue to store messages as the
> spoke broker. We are need a restart of the broker to reestablish the network
> bridge.
> Relevant Logs:
> 2016-09-22 14:21:40,105 | WARN | tyMonitor Worker |
> DemandForwardingBridgeSupport| 20 - org.apache.activemq.activemq-osgi -
> 5.13.3 | Network connection between vm://central-amq-broker#44 and
> tcp:///xx.xxx.xx.xx:53103@61616 shutdown due to a remote error:
> org.apache.activemq.transport.InactivityIOException: Channel was inactive for
> too (>3) long: tcp:///xx.xxx.xx.xx:53103
> 2016-09-22 14:21:40,117 | INFO | -broker] Task-21 |
> DemandForwardingBridgeSupport| 20 - org.apache.activemq.activemq-osgi -
> 5.13.3 | central-amq-broker bridge to T1-amq-broker stopped
> 2016-09-22 14:23:44,246 | INFO | eMQ NIO Worker 4 | TransportConnection
> | 20 - org.apache.activemq.activemq-osgi - 5.13.3 | Started responder
> end of duplex bridge T:broker1->broker2@ID:T1-35496-147472634-0:1
> 2016-09-22 14:23:44,255 | INFO | al-amq-broker#52 |
> DemandForwardingBridgeSupport| 20 - org.apache.activemq.activemq-osgi -
> 5.13.3 | Network connection between vm://central-amq-broker#52 and
> tcp:///xx.xxx.xx.xx:53162@61616 (T1-amq-broker) has been established.
> Network Connector on Spoke Broker:
>
> name="T:broker1->broker2"
> userName="karaf"
> password="karaf"
>
> uri="masterslave:(tcp://${ACTIVEMQ_HEAD_1_IP_ADDRESS}:61616,tcp://${ACTIVEMQ_HEAD_2_IP_ADDRESS}:61616)"
> duplex="true"
> decreaseNetworkConsumerPriority="true"
> networkTTL="2"
> dynamicOnly="true">
>
>
>
>
>
> name="Q:broker1->broker2"
> userName="karaf"
> password="karaf"
>
> uri="masterslave:(tcp://${ACTIVEMQ_HEAD_1_IP_ADDRESS}:61616,tcp://${ACTIVEMQ_HEAD_2_IP_ADDRESS}:61616)"
> duplex="true"
> decreaseNetworkConsumerPriority="true"
> networkTTL="2"
> dynamicOnly="true">
>
>
>
>
>
> Test to Recreate:
> To recreate this issue, we can block the network between the two hosts while
> simulating some load
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (AMQ-6692) Broker hangs after file writting exception
Andrei Shakirin created AMQ-6692: Summary: Broker hangs after file writting exception Key: AMQ-6692 URL: https://issues.apache.org/jira/browse/AMQ-6692 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.13.4 Reporter: Andrei Shakirin -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMQ-6589) Broker hangs by shutdown after loosing exclusive lock
[
https://issues.apache.org/jira/browse/AMQ-6589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031034#comment-16031034
]
Andrei Shakirin commented on AMQ-6589:
--
The issue is happens time to time again.
By last occurance broker needs ~ 1 hour to stop:
{code}
2017-05-29 15:33:37,209 | INFO | Lock file /CE/activemq/ESB_K2/lock, locked at
Sun May 28 17:50:14 CEST 2017, has been modified at Mon May 29 15:33:36 CEST
2017 | org.apache.activemq.util.LockFile | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:33:37,210 | ERROR | degtlun5214, no longer able to keep the
exclusive lock so giving up being a master |
org.apache.activemq.broker.LockableServiceSupport | ActiveMQ Lock KeepAlive
Timer
2017-05-29 15:33:37,224 | INFO | Apache ActiveMQ 5.13.4 (degtlun5214,
ID:degtlun5214-48167-1495986717775-1:1) is shutting down |
org.apache.activemq.broker.BrokerService | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:33:42,227 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:33:47,227 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:33:52,228 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:33:57,228 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:34:02,229 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:34:07,229 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 15:34:12,229 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
...
2017-05-29 16:24:07,453 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 16:24:12,453 | INFO | The connection to
'tcp://172.26.244.150:40032' is taking a long time to shutdown. |
org.apache.activemq.broker.TransportConnection | ActiveMQ Lock KeepAlive Timer
2017-05-29 16:24:38,999 | INFO | Refreshing
org.apache.activemq.xbean.XBeanBrokerFactory$1@27c20538: startup date [Mon May
29 16:24:38 CEST 2017]; root of context hierarchy |
org.apache.activemq.xbean.XBeanBrokerFactory$1 | main
2017-05-29 16:24:40,025 | INFO | Using Persistence Adapter:
MultiKahaDBPersistenceAdapter[/CE/activemq/ESB_K2][] |
org.apache.activemq.broker.BrokerService | main
{code}
Any chance to investigate and fix it?
> Broker hangs by shutdown after loosing exclusive lock
> -
>
> Key: AMQ-6589
> URL: https://issues.apache.org/jira/browse/AMQ-6589
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.4
> Environment: Linux
>Reporter: Andrei Shakirin
> Attachments: activemq-old-master-anonymized.log, activemq.xml
>
>
> 1) Configuration: ActiveMQ brokers are configured with shared store (NFS) and
> shared file locker with configured lockAcquireSleepInterval:
> {code:xml}
>
>
>
>
>
>
>
>
>checkForCorruptJournalFiles="true" checksumJournalFiles="true" />
>
>
>
>
>
> {code}
> 2) Workflow
> The master broker looses exclusive lock and tries to shutdown, it is reported
> in the log file:
> {code}
> 2017-01-31 16:30:45,921 | INFO | Lock file /CE/activemq/lock, locked at Thu
> Jan 05 01:14:11 CET 2017, has been modified at Tue Jan 31 16:30:45 CET 2017 |
> org.apache.activemq.util.LockFile | ActiveMQ Lock KeepAlive Timer
> 2017-01-31 16:30:45,921 | ERROR | hostXXX, no longer able to keep the
> exclusive lock so giving up being a master |
> org.apache.activemq.broker.LockableServiceSupport | ActiveMQ Lock KeepAlive
> Timer
> 2017-01-31 16:30:45,924 | INFO | Apache ActiveMQ 5.13.4 (hostXXX,
> ID:xxx-36540-1483575278364-0:1) is shutting down |
> org.apache.activemq.broker.BrokerService | ActiveMQ Lock KeepAliv
[jira] [Resolved] (AMQ-6691) JMX - allow DLQ flag to be modified
[ https://issues.apache.org/jira/browse/AMQ-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-6691. - Resolution: Fixed Assignee: Gary Tully Test that validates persistence of the dlq flag via the destinations element of the broker xml is at: https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=commit;h=18d05ba5e0a96d231a357eb0a20b1f6388cb6c49 > JMX - allow DLQ flag to be modified > --- > > Key: AMQ-6691 > URL: https://issues.apache.org/jira/browse/AMQ-6691 > Project: ActiveMQ > Issue Type: Improvement > Components: JMX >Affects Versions: 5.14.0 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.15.0 > > > AMQ-4483 introduces the destination flag but it is not persisted in the > message store and does not survive a restart. > Adding the flag to the destinations element in the broker xml works around > this however it assumes prior knowledge. > Allowing the flag to be set allows a retrospective change pending the next > restart when a modification to the destinations element can be picked up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMQ-6691) JMX - allow DLQ flag to be modified
[ https://issues.apache.org/jira/browse/AMQ-6691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031023#comment-16031023 ] ASF subversion and git services commented on AMQ-6691: -- Commit d2c0eddaad7a5633d50c9a1fef2014b9fc0fb5bc in activemq's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=d2c0edd ] [AMQ-6691] allow dlq flag to be set via jmx to allow retry op after a restart - use destinations element for long term persistence > JMX - allow DLQ flag to be modified > --- > > Key: AMQ-6691 > URL: https://issues.apache.org/jira/browse/AMQ-6691 > Project: ActiveMQ > Issue Type: Improvement > Components: JMX >Affects Versions: 5.14.0 >Reporter: Gary Tully > Fix For: 5.15.0 > > > AMQ-4483 introduces the destination flag but it is not persisted in the > message store and does not survive a restart. > Adding the flag to the destinations element in the broker xml works around > this however it assumes prior knowledge. > Allowing the flag to be set allows a retrospective change pending the next > restart when a modification to the destinations element can be picked up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMQ-6691) JMX - allow DLQ flag to be modified
Gary Tully created AMQ-6691: --- Summary: JMX - allow DLQ flag to be modified Key: AMQ-6691 URL: https://issues.apache.org/jira/browse/AMQ-6691 Project: ActiveMQ Issue Type: Improvement Components: JMX Affects Versions: 5.14.0 Reporter: Gary Tully Fix For: 5.15.0 AMQ-4483 introduces the destination flag but it is not persisted in the message store and does not survive a restart. Adding the flag to the destinations element in the broker xml works around this however it assumes prior knowledge. Allowing the flag to be set allows a retrospective change pending the next restart when a modification to the destinations element can be picked up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1186) Consumer.receive hangs if http acceptor with non-zero batch-delay is configured
[
https://issues.apache.org/jira/browse/ARTEMIS-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030982#comment-16030982
]
Tomas Hofman commented on ARTEMIS-1186:
---
master PR: https://github.com/apache/activemq-artemis/pull/1297
1.6 PR: https://github.com/apache/activemq-artemis/pull/1309
1.5.5 PR: https://github.com/rh-messaging/jboss-activemq-artemis/pull/191
> Consumer.receive hangs if http acceptor with non-zero batch-delay is
> configured
> ---
>
> Key: ARTEMIS-1186
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1186
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> Test scenario:
> # Call consumer.receive(1000) on empty queue.
> # Check whether receive call is unblocked after the 1 second.
> Issue: The receive call is not unblocked.
> I hit the issue which was initially reported in JBEAP-6443. I found out that
> the issue is somehow related to http connectors/acceptors and {{batch-delay}}
> parameter. I am able to reproduce it only if a client connects via
> http-connector with non-zero batch-delay. When I tried classic
> {{remote-connector}}, everything worked with both zero and non-zero
> {{batch-delay}}.
> I am able to reproduce the issue with both Artemis 1.1 (EAP 7.0.3) and
> Artemis 1.4.
> From the thread dump, you can see where the client hangs.
> {code}
> Stack trace of thread: Thread[Thread-10,5,main]
> ---java.lang.Object.wait(Native Method)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:258)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:391)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:198)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:122)
> ---org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:140)
> ---org.jboss.qa.hornetq.apps.clients.ReceiverAutoAck.run(ReceiverAutoAck.java:75)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (AMQ-6690) Protect against JMX move/copy operations onto self
[ https://issues.apache.org/jira/browse/AMQ-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-6690. - Resolution: Fixed I considered throwing an exception but I think it is safer to retain the existing behaviour and report via the return code > Protect against JMX move/copy operations onto self > -- > > Key: AMQ-6690 > URL: https://issues.apache.org/jira/browse/AMQ-6690 > Project: ActiveMQ > Issue Type: Improvement > Components: JMX >Affects Versions: 5.14.0 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.15.0 > > > The move and copy jmx operations are intended to move/copy messages to > another destination. However this is not enforce and if the move/copy > destination is the same queue the logs fill with duplicate warnings etc and > the stats can get out of sync if the operation is repeated or concurrent. > Best to cut this off at the pass with a return return code indicating nothing > was moved/copied. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1186) Consumer.receive hangs if http acceptor with non-zero batch-delay is configured
[
https://issues.apache.org/jira/browse/ARTEMIS-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030969#comment-16030969
]
ASF GitHub Bot commented on ARTEMIS-1186:
-
GitHub user TomasHofman opened a pull request:
https://github.com/apache/activemq-artemis/pull/1309
ARTEMIS-1186 Consumer.receive hangs if http acceptor with non-zero ba…
…tch-delay is configured
https://issues.apache.org/jira/browse/ARTEMIS-1186
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/TomasHofman/activemq-artemis JBEAP-6570-1.x
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/1309.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1309
commit 9085b6d617d9f3445a24b5a19ecf4e27519995a8
Author: Tomas Hofman
Date: 2017-05-29T10:00:32Z
ARTEMIS-1186 Consumer.receive hangs if http acceptor with non-zero
batch-delay is configured
> Consumer.receive hangs if http acceptor with non-zero batch-delay is
> configured
> ---
>
> Key: ARTEMIS-1186
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1186
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> Test scenario:
> # Call consumer.receive(1000) on empty queue.
> # Check whether receive call is unblocked after the 1 second.
> Issue: The receive call is not unblocked.
> I hit the issue which was initially reported in JBEAP-6443. I found out that
> the issue is somehow related to http connectors/acceptors and {{batch-delay}}
> parameter. I am able to reproduce it only if a client connects via
> http-connector with non-zero batch-delay. When I tried classic
> {{remote-connector}}, everything worked with both zero and non-zero
> {{batch-delay}}.
> I am able to reproduce the issue with both Artemis 1.1 (EAP 7.0.3) and
> Artemis 1.4.
> From the thread dump, you can see where the client hangs.
> {code}
> Stack trace of thread: Thread[Thread-10,5,main]
> ---java.lang.Object.wait(Native Method)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:258)
> ---org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.receive(ClientConsumerImpl.java:391)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:198)
> ---org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:122)
> ---org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:140)
> ---org.jboss.qa.hornetq.apps.clients.ReceiverAutoAck.run(ReceiverAutoAck.java:75)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (AMQ-6690) Protect against JMX move/copy operations onto self
[ https://issues.apache.org/jira/browse/AMQ-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030958#comment-16030958 ] ASF subversion and git services commented on AMQ-6690: -- Commit 8023b9ee448d2ed52c8a5c84b40dd92aae8bfc88 in activemq's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=8023b9e ] [AMQ-6690] do nothing for move/copy jmx ops that try to modify self > Protect against JMX move/copy operations onto self > -- > > Key: AMQ-6690 > URL: https://issues.apache.org/jira/browse/AMQ-6690 > Project: ActiveMQ > Issue Type: Improvement > Components: JMX >Affects Versions: 5.14.0 >Reporter: Gary Tully >Assignee: Gary Tully > Fix For: 5.15.0 > > > The move and copy jmx operations are intended to move/copy messages to > another destination. However this is not enforce and if the move/copy > destination is the same queue the logs fill with duplicate warnings etc and > the stats can get out of sync if the operation is repeated or concurrent. > Best to cut this off at the pass with a return return code indicating nothing > was moved/copied. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (AMQ-6690) Protect against JMX move/copy operations onto self
Gary Tully created AMQ-6690: --- Summary: Protect against JMX move/copy operations onto self Key: AMQ-6690 URL: https://issues.apache.org/jira/browse/AMQ-6690 Project: ActiveMQ Issue Type: Improvement Components: JMX Affects Versions: 5.14.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 5.15.0 The move and copy jmx operations are intended to move/copy messages to another destination. However this is not enforce and if the move/copy destination is the same queue the logs fill with duplicate warnings etc and the stats can get out of sync if the operation is repeated or concurrent. Best to cut this off at the pass with a return return code indicating nothing was moved/copied. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARTEMIS-1198) Add listAllSessionsAsJSON
Daniel Siviter created ARTEMIS-1198:
---
Summary: Add listAllSessionsAsJSON
Key: ARTEMIS-1198
URL: https://issues.apache.org/jira/browse/ARTEMIS-1198
Project: ActiveMQ Artemis
Issue Type: Improvement
Components: Broker
Affects Versions: 2.1.0
Reporter: Daniel Siviter
A {{listAllConsumersAsJSON}} already exists, but it would be useful to get the
same for ServerSessions with a {{listAllSessionsAsJSON}} to find all sessions
connected rather than just per connection (i.e. {{listSessionsAsJSON}}). The
vast majority of connections will only have one session (especially STOMP,
AMQP, etc.,) so iterating round and calling {{listSessionsAsJSON}} is onerous.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1185) Inter-Process Journal Sampler Profiler + CLI command
[ https://issues.apache.org/jira/browse/ARTEMIS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030839#comment-16030839 ] ASF GitHub Bot commented on ARTEMIS-1185: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1295 @clebertsuconic > doc how to use this... (is that internal only)? :+1: You're right, but what could be a good place where put it? It is like the other CLI commands, so it can be used by any user, but I suspect that perf engineers and devOps engineers are the typical audience for it. A possible use case is to build a Cron job that during the day run it and use the extracted log to feed a time series database, an Elastic Search repository or anything suitable to collect latency samples. After the doc probably most of the aspect of the profiler will be clear, it uses an approach similar to perf tools on *nix. > how to read the file... The *profiler* (ie FlushProfiler) produces only one file of 4K fixed size in `/dev/shm` or in the Artemis configured `tmp` dir: this file is not built to be read by humans or other user-provided tools right now. > I am a bit confused with the file format... The *sampler* (ie the CLI command) samples the data on the file written by the *profiler* and produces a CSV US-ASCII text trace with `\n` pairs. For example, using the default parameters: ``` 0 27729 4534870 32709 8443760 27556 15067045 44260 16290386 18286 17146291 14201 17908462 8243 19349526 33071 24171483 79496 27741532 18992 ... ``` This trace, if collected in a file, can be used directly with `gnuplot` to plot this:  But it won't be saved in a file if not configured properly. > Also, it would be nice to be allowed to configure where the file would be generated. Currently the user running the *sampler* could choose where put the trace recorded from the profiler using the `--out` parameter: ``` @Option(name = "--out", description = "The output text csv stat file or stdout if not defined") public String fileOut; ``` By default the *sampler* command prints on `stdout` the CSV trace and on `stderr` a real time log of the statistics of the running sampler, in the form: ``` Duration 1003ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1000ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 657 sample - 4 lost - 780 kB - 657 sync Duration 1002ms - 3,397 sample - 0 lost - 4,413 kB - 3,397 sync Duration 1001ms - 4,328 sample - 14 lost - 5,827 kB - 4,328 sync Duration 1001ms - 4,807 sample - 2 lost - 6,513 kB - 4,807 sync Duration 1000ms - 2,100 sample - 0 lost - 2,847 kB - 2,100 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 2,994 sample - 0 lost - 4,051 kB - 2,994 sync Duration 1001ms - 5,165 sample - 0 lost - 7,001 kB - 5,165 sync Duration 1000ms - 5,244 sample - 0 lost - 7,116 kB - 5,244 sync Duration 1001ms - 1,647 sample - 0 lost - 2,230 kB - 1,647 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1000ms - 3,237 sample - 0 lost - 4,381 kB - 3,237 sync Duration 1001ms - 4,892 sample - 0 lost - 6,616 kB - 4,892 sync Duration 1001ms - 4,543 sample - 0 lost - 6,120 kB - 4,543 sync Duration 1000ms - 2,468 sample - 0 lost - 3,281 kB - 2,468 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 1,747 sample - 1 lost - 2,374 kB - 1,747 sync Duration 1000ms - 5,318 sample - 0 lost - 7,224 kB - 5,318 sync Duration 1001ms - 5,327 sample - 0 lost - 7,233 kB - 5,327 sync Duration 1001ms - 2,628 sample - 0 lost - 3,565 kB - 2,628 sync Duration 1000ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 2,553 sample - 0 lost - 3,451 kB - 2,553 sync Duration 1001ms - 5,243 sample - 0 lost - 7,108 kB - 5,243 sync Duration 1001ms - 5,162 sample - 0 lost - 7,008 kB - 5,162 sync Duration 1000ms - 2,087 sample - 0 lost - 2,831 kB - 2,087 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 3,011 sample - 0 lost - 4,090 kB - 3,011 sync Duration 1001ms - 6,720 sample - 0 lost - 9,116 kB - 6,720 sync Duration 1000ms - 5,306 sample - 0 lost - 7,193 kB - 5,306 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1000ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1001ms - 0 sample - 0 lost - 0 bytes - 0 sync Duration 1000ms - 0 sample - 0 lost -
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[
https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030830#comment-16030830
]
ASF GitHub Bot commented on ARTEMIS-1196:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1307#discussion_r119298068
--- Diff:
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/karaf/ArtemisFeatureTest.java
---
@@ -146,11 +155,26 @@ public Boolean call() throws Exception {
connection = factory.createConnection(USER, PASSWORD);
connection.start();
- javax.jms.Session sess = connection.createSession(false,
javax.jms.Session.AUTO_ACKNOWLEDGE);
+ QueueSession sess = (QueueSession)
connection.createSession(false, javax.jms.Session.AUTO_ACKNOWLEDGE);
Queue queue = sess.createQueue("exampleQueue");
MessageProducer producer = sess.createProducer(queue);
producer.send(sess.createTextMessage("TEST"));
+ // Test management
+ Queue managementQueue = sess.createQueue("activemq.management");
+ QueueRequestor requestor = new QueueRequestor(sess,
managementQueue);
+ connection.start();
+ TextMessage m = sess.createTextMessage();
+ m.setStringProperty("_AMQ_ResourceName", "broker");
+ m.setStringProperty("_AMQ_OperationName", "getQueueNames");
+ m.setText("[\"ANYCAST\"]");
+ Message reply = requestor.request(m);
+ String json = ((TextMessage) reply).getText();
+ JsonArray array = Json.createReader(new
StringReader(json)).readArray();
+ List queues = (List) array.get(0);
+ assertNotNull(queues);
+
System.out.println(queues.stream().map(JsonString::getString).collect(Collectors.joining(",
", "Queues: ", "")));
--- End diff --
System out? I assume this is left over from debugging
> Unusable JSON api on Karaf
> --
>
> Key: ARTEMIS-1196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1196
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Fix For: 2.2.0
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[ https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030826#comment-16030826 ] ASF GitHub Bot commented on ARTEMIS-1196: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/1307 Thanks for adding a test. > Unusable JSON api on Karaf > -- > > Key: ARTEMIS-1196 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1196 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1187) Incompatible version when recreating a session with older server
[
https://issues.apache.org/jira/browse/ARTEMIS-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030820#comment-16030820
]
ASF GitHub Bot commented on ARTEMIS-1187:
-
Github user TomasHofman commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1298#discussion_r119296506
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ActiveMQSessionContext.java
---
@@ -686,7 +686,7 @@ protected CreateSessionMessage newCreateSession(String
username,
boolean autoCommitSends,
boolean autoCommitAcks,
boolean preAcknowledge)
{
- return new CreateSessionMessage(name, sessionChannel.getID(),
VersionLoader.getVersion().getIncrementingVersion(), username, password,
minLargeMessageSize, xa, autoCommitSends, autoCommitAcks, preAcknowledge,
confirmationWindow, null);
+ return new CreateSessionMessage(name, sessionChannel.getID(),
serverVersion, username, password, minLargeMessageSize, xa, autoCommitSends,
autoCommitAcks, preAcknowledge, confirmationWindow, null);
--- End diff --
The ```newCreateSession()``` is only called in ```recreateSession()```
method, so my reasoning was that the message will be sent to the same server
that the client was previously connected to (is that correct?), so the
serverVersion that was previously established can be reused.
The alternative could be to start a cycle of CreateSessionMessages with the
highest know version and decrease the version if
```ActiveMQIncompatibleClientServerException``` is returned? I think this is
how establishing new connection works.
> Incompatible version when recreating a session with older server
>
>
> Key: ARTEMIS-1187
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1187
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Tomas Hofman
>
> 1.5.x client is able to connect to 1.1.x server. However, when server is
> reloaded following error occurs:
> {noformat}
> 11:42:29,400 Thread-0 (ActiveMQ-client-global-threads-1319762469) ERROR
> [org.apache.activemq.artemis.core.client.impl.ClientSessionImpl:993]
> AMQ214003: Failed to handle failover
>
> ActiveMQIncompatibleClientServerException[errorType=INCOMPATIBLE_CLIENT_SERVER_VERSIONS
> message=AMQ119033: Server and client versions incompatible]
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:407)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:318)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.recreateSession(ActiveMQSessionContext.java:637)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.handleFailover(ClientSessionImpl.java:958)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.reconnectSessions(ClientSessionFactoryImpl.java:771)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.failoverOrReconnect(ClientSessionFactoryImpl.java:614)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.handleConnectionFailure(ClientSessionFactoryImpl.java:504)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.access$500(ClientSessionFactoryImpl.java:72)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$DelegatingFailureListener.connectionFailed(ClientSessionFactoryImpl.java:1165)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:67)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:207)
> at
> org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:215)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$CloseRunnable.run(ClientSessionFactoryImpl.java:996)
> at
> org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:101)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> This works correctly with 1.5 server and old
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[ https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030769#comment-16030769 ] ASF GitHub Bot commented on ARTEMIS-1196: - Github user gnodet commented on the issue: https://github.com/apache/activemq-artemis/pull/1307 Not to be committed yet I think, as it depends on a SNAPSHOT. I'll ping when the spec has been released. > Unusable JSON api on Karaf > -- > > Key: ARTEMIS-1196 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1196 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1197) Missing browse permission on Karaf
[ https://issues.apache.org/jira/browse/ARTEMIS-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030765#comment-16030765 ] ASF GitHub Bot commented on ARTEMIS-1197: - GitHub user gnodet opened a pull request: https://github.com/apache/activemq-artemis/pull/1308 [ARTEMIS-1197] Add missing role to default OSGi configuration You can merge this pull request into a Git repository by running: $ git pull https://github.com/gnodet/activemq-artemis ARTEMIS-1197 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1308.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1308 commit a81ac3ac6b558e6abbe433b9f54b545590f4bd90 Author: Guillaume Nodet Date: 2017-05-19T08:00:59Z [ARTEMIS-1197] Add missing role to default OSGi configuration > Missing browse permission on Karaf > -- > > Key: ARTEMIS-1197 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1197 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1196) Unusable JSON api on Karaf
[ https://issues.apache.org/jira/browse/ARTEMIS-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030764#comment-16030764 ] ASF GitHub Bot commented on ARTEMIS-1196: - GitHub user gnodet opened a pull request: https://github.com/apache/activemq-artemis/pull/1307 [ARTEMIS-1196] Fix missing JSON support You can merge this pull request into a Git repository by running: $ git pull https://github.com/gnodet/activemq-artemis ARTEMIS-1196 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1307.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1307 commit cc938afc745347fb81e98cacd18d1eb7fd961811 Author: Guillaume Nodet Date: 2017-05-19T08:01:53Z [ARTEMIS-1196] Fix missing JSON support > Unusable JSON api on Karaf > -- > > Key: ARTEMIS-1196 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1196 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1176) Use text messages for management reply messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030749#comment-16030749 ] ASF GitHub Bot commented on ARTEMIS-1176: - Github user gnodet closed the pull request at: https://github.com/apache/activemq-artemis/pull/1305 > Use text messages for management reply messages > --- > > Key: ARTEMIS-1176 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1176 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1185) Inter-Process Journal Sampler Profiler + CLI command
[
https://issues.apache.org/jira/browse/ARTEMIS-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030746#comment-16030746
]
ASF GitHub Bot commented on ARTEMIS-1185:
-
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1295#discussion_r119284924
--- Diff:
artemis-journal/src/main/java/org/apache/activemq/artemis/core/io/buffer/TimedBuffer.java
---
@@ -93,10 +82,10 @@
public TimedBuffer(final int size, final int timeout, final boolean
logRates) {
bufferSize = size;
- this.logRates = logRates;
-
if (logRates) {
--- End diff --
Good point!I'll change the name in something more appropriate :+1:
> Inter-Process Journal Sampler Profiler + CLI command
>
>
> Key: ARTEMIS-1185
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1185
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Components: Broker
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>Priority: Minor
>
> It provides a sampling profiler on buffered ASYNCIO/NIO based journals.
> The profiling has a minimal cost in term of CPU time for each sample (the
> dominant costs are System.nanoTime() and a single cache line invalidation)
> and total memory footprint (~OS page size in bytes).
> A proper CLI command activates a sampler to collect (ie CSV) the profiled
> data, showing the precision of the sampling: data loss is not considered a
> failure condition.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ARTEMIS-1176) Use text messages for management reply messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved ARTEMIS-1176. -- Resolution: Fixed > Use text messages for management reply messages > --- > > Key: ARTEMIS-1176 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1176 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARTEMIS-1197) Missing browse permission on Karaf
Guillaume Nodet created ARTEMIS-1197: Summary: Missing browse permission on Karaf Key: ARTEMIS-1197 URL: https://issues.apache.org/jira/browse/ARTEMIS-1197 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARTEMIS-1196) Unusable JSON api on Karaf
Guillaume Nodet created ARTEMIS-1196: Summary: Unusable JSON api on Karaf Key: ARTEMIS-1196 URL: https://issues.apache.org/jira/browse/ARTEMIS-1196 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 2.2.0 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1176) Use text messages for management reply messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030748#comment-16030748 ] ASF GitHub Bot commented on ARTEMIS-1176: - Github user gnodet commented on the issue: https://github.com/apache/activemq-artemis/pull/1305 The problem has already been fixed it seems. > Use text messages for management reply messages > --- > > Key: ARTEMIS-1176 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1176 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet > Fix For: 2.2.0 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
