[jira] [Created] (AMQ-6053) java.lang.ClassCastException while removing the inactive durable subscriber
Luigi Corollo created AMQ-6053:
--
Summary: java.lang.ClassCastException while removing the inactive
durable subscriber
Key: AMQ-6053
URL: https://issues.apache.org/jira/browse/AMQ-6053
Project: ActiveMQ
Issue Type: Bug
Components: Broker, Message Store
Affects Versions: 5.11.2
Environment: ActiveMQ 5.11.2 , master slave with kahadb
Reporter: Luigi Corollo
Hi,
we have a problem with the removing an inactive durable subscription after
certain period of inactivity.
It throws java.lang.ClassCastException.
Broker Config:
http://activemq.apache.org/schema/core;
brokerName="localhost" dataDirectory="${activemq.data}" useJmx="true"
schedulerSupport="true" offlineDurableSubscriberTimeout="6"
offlineDurableSubscriberTaskSchedule="3">
Log:
ERROR | Failed to remove inactive durable subscriber
java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String
at java.lang.String.compareTo(String.java:108)[:1.7.0_79]
at java.util.Arrays.binarySearch0(Arrays.java:1481)[:1.7.0_79]
at java.util.Arrays.binarySearch(Arrays.java:1423)[:1.7.0_79]
at
org.apache.activemq.store.kahadb.disk.index.BTreeNode.contains(BTreeNode.java:707)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.disk.index.BTreeIndex.containsKey(BTreeIndex.java:179)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.getDeleteList(MessageDatabase.java:2951)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase.removeAckLocationsForSub(MessageDatabase.java:2274)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase.updateIndex(MessageDatabase.java:1482)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase$15.execute(MessageDatabase.java:1207)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase.process(MessageDatabase.java:1204)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase$10.visit(MessageDatabase.java:1103)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.data.KahaSubscriptionCommand.visit(KahaSubscriptionCommand.java:187)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase.process(MessageDatabase.java:1070)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase.store(MessageDatabase.java:977)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.MessageDatabase.store(MessageDatabase.java:957)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.deleteSubscription(KahaDBStore.java:807)[activemq-kahadb-store-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.ProxyTopicMessageStore.deleteSubscription(ProxyTopicMessageStore.java:103)[activemq-broker-5.11.2.jar:5.11.2]
at
org.apache.activemq.store.ProxyTopicMessageStore.deleteSubscription(ProxyTopicMessageStore.java:103)[activemq-broker-5.11.2.jar:5.11.2]
at
org.apache.activemq.broker.region.Topic.deleteSubscription(Topic.java:201)[activemq-broker-5.11.2.jar:5.11.2]
at
org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:213)[activemq-broker-5.11.2.jar:5.11.2]
at
org.apache.activemq.broker.region.TopicRegion.doCleanup(TopicRegion.java:100)[activemq-broker-5.11.2.jar:5.11.2]
at
org.apache.activemq.broker.region.TopicRegion$1.run(TopicRegion.java:70)[activemq-broker-5.11.2.jar:5.11.2]
at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_79]
at java.util.TimerThread.run(Timer.java:505)[:1.7.0_79]
Thanks,
Luigi
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6048) ActiveMQ broker service hanged after re-establishing the connection with another ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-6048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014136#comment-15014136 ] Timothy Bish commented on AMQ-6048: --- Recommend you retest using the latest release of ActiveMQ v5.12.1 > ActiveMQ broker service hanged after re-establishing the connection with > another ActiveMQ > - > > Key: AMQ-6048 > URL: https://issues.apache.org/jira/browse/AMQ-6048 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.0 > Environment: Windows server 2003 >Reporter: Anas Abu Shawish > > We've encountered this incident on ActiveMQ broker wrapper logs where a > disconnections happened between the broker and other ActiveMQ service. The > network disconnection happened for almost a day and then an outofMemory > exception started to appear. Then the connection was re-established and with > the other MQ service and broker started to process one file then it hanged > and no logs were found afterwards until ActiveMQ broker windows service > restarted. > A snap of the error appeared in wrapper.log file : > INFO | jvm 1| 2015/10/30 07:58:39 | Exception in thread "ActiveMQ > Failover Worker: 23334009" java.lang.OutOfMemoryError: unable to create new > native thread > INFO | jvm 1| 2015/10/30 07:58:39 | at > java.lang.Thread.start0(Native Method) > INFO | jvm 1| 2015/10/30 07:58:39 | at > java.lang.Thread.start(Thread.java:714) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.thread.TaskRunnerFactory.doExecuteNewThread(TaskRunnerFactory.java:165) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.thread.TaskRunnerFactory.execute(TaskRunnerFactory.java:155) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.thread.TaskRunnerFactory.execute(TaskRunnerFactory.java:146) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.tcp.TcpTransport.doStop(TcpTransport.java:538) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.nio.NIOTransport.doStop(NIOTransport.java:166) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.util.ServiceSupport.stop(ServiceSupport.java:71) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.tcp.TcpTransport.stop(TcpTransport.java:582) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.AbstractInactivityMonitor.stop(AbstractInactivityMonitor.java:145) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.TransportFilter.stop(TransportFilter.java:65) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.WireFormatNegotiator.stop(WireFormatNegotiator.java:91) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1079) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:149) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:112) > INFO | jvm 1| 2015/10/30 07:58:39 | at > org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:42) > INFO | jvm 1| 2015/10/30 07:59:39 | INFO | Successfully reconnected to > nio://wps-server1.systems.qa.hsbc:61999 > INFO | jvm 1| 2015/10/31 07:01:13 | INFO | *** Compressing SIF file : > 'SIF_10370600_HSB_20151031_0701.CSV' > INFO | jvm 1| 2015/10/31 07:01:14 | INFO | *** Sending SIF file... > Appreciate if anyone can help in identifying the root cause of the issue. > Regards, -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-6051) ActiveMQConnection leaking thread when resources are not well closed
[
https://issues.apache.org/jira/browse/AMQ-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQ-6051.
---
Resolution: Fixed
Assignee: Timothy Bish
Fix Version/s: 5.13.0
Fix applied with thanks.
> ActiveMQConnection leaking thread when resources are not well closed
>
>
> Key: AMQ-6051
> URL: https://issues.apache.org/jira/browse/AMQ-6051
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.12.0
>Reporter: Romain Manni-Bucau
>Assignee: Timothy Bish
> Fix For: 5.13.0
>
>
> ActiveMQConnection starts a session task thread but doesnt close it if
> close() is called and the broker doesnt respond
> {code}
> try {
> if (isConnectionInfoSentToBroker) {
> // If we announced ourselves to the broker.. Try
> to let the broker
> // know that the connection is being shutdown.
> RemoveInfo removeCommand =
> info.createRemoveCommand();
>
> removeCommand.setLastDeliveredSequenceId(lastDeliveredSequenceId);
> try {
> doSyncSendPacket(removeCommand, closeTimeout);
> } catch (JMSException e) {
> if (e.getCause() instanceof
> RequestTimedOutIOException) {
> // expected
> } else {
> throw e;
> }
> }
> doAsyncSendPacket(new ShutdownInfo());
> }
> } finally {
> // ensure we clean up this connection anyway even if
> previous send fail
> // which can happen if we lost the connection with
> the broker
> started.set(false);
> // TODO if we move the TaskRunnerFactory to the
> connection
> // factory
> // then we may need to call
> // factory.onConnectionClose(this);
> if (sessionTaskRunner != null) {
> sessionTaskRunner.shutdown();
> }
> closed.set(true);
> closing.set(false);
> }
> {code}
> solves it
> tested on 5.12.0 but 5.12.x has the same code so I guess it has the same issue
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-201) Log warning if server can crash on OutOfMemory due to "misconfiguration"
[ https://issues.apache.org/jira/browse/ARTEMIS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-201: -- Assignee: Justin Bertram > Log warning if server can crash on OutOfMemory due to "misconfiguration" > > > Key: ARTEMIS-201 > URL: https://issues.apache.org/jira/browse/ARTEMIS-201 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.0.0 >Reporter: Miroslav Novak >Assignee: Justin Bertram > > Imagine situation where server is started with 3000 destinations and > max-size-bytes is set to 10MB. This would mean that JVM would have to be > started with at least 30GB of memory to prevent OOM in case that all > destinations get filled up. (PAGE mode is not a solution in this case as it > starts once destination exceeds 10MB in memory) > Purpose of this jira is to provide check which would print warning in case > that such OOM can happen. This check would be executed during start of server > and then with adding any destination at runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-201) Log warning if server can crash on OutOfMemory due to "misconfiguration"
[ https://issues.apache.org/jira/browse/ARTEMIS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014674#comment-15014674 ] Justin Bertram commented on ARTEMIS-201: I will add this check for when the server is started. For memory related warnings during runtime the user can configure a memory-measure-interval > 0 and an appropriate memory-warning-threshold. > Log warning if server can crash on OutOfMemory due to "misconfiguration" > > > Key: ARTEMIS-201 > URL: https://issues.apache.org/jira/browse/ARTEMIS-201 > Project: ActiveMQ Artemis > Issue Type: New Feature > Components: Broker >Affects Versions: 1.0.0 >Reporter: Miroslav Novak >Assignee: Justin Bertram > > Imagine situation where server is started with 3000 destinations and > max-size-bytes is set to 10MB. This would mean that JVM would have to be > started with at least 30GB of memory to prevent OOM in case that all > destinations get filled up. (PAGE mode is not a solution in this case as it > starts once destination exceeds 10MB in memory) > Purpose of this jira is to provide check which would print warning in case > that such OOM can happen. This check would be executed during start of server > and then with adding any destination at runtime. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQNET-513) Exception message is not propagated in case of consumption failure
[
https://issues.apache.org/jira/browse/AMQNET-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014727#comment-15014727
]
Timothy Bish commented on AMQNET-513:
-
Feel free to build from trunk or 1.7.x branch and see if that resolves your
problem.
> Exception message is not propagated in case of consumption failure
> --
>
> Key: AMQNET-513
> URL: https://issues.apache.org/jira/browse/AMQNET-513
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: NMS
>Affects Versions: 1.6.2, 1.7.0, 1.7.1
>Reporter: Maxim Cherednik
>Assignee: Jim Gomes
>
> After moving from version 1.6.2 to 1.7 we lost some functionality we were
> relying on.
> When we were failing to process message 6 times, it was moved to the
> Activemq.DLQ and the property dlqDeliveryFailureCause was filled with
> Exception message which was raised during the processing.
> After version update - the exception message is not propagated. This message
> instead:
> javax.jms.JMSException: Exceeded RedeliveryPolicy limit: 6
> Maybe there are other way to track which client failed to process message and
> why(exception message) ?
> Code sample:
> {code:title=Consumer.cs|borderStyle=solid}
> static void Consume()
> {
> var brokerUri = "";
> var clientId = "test";
> var connFactory = new ConnectionFactory(brokerUri, clientId);
> _connection = connFactory.CreateConnection();
> _connection.ExceptionListener += _connection_ExceptionListener;
> _connection.ConnectionResumedListener +=
> _connection_ConnectionResumedListener;
> _connection.ConnectionInterruptedListener +=
> _connection_ConnectionInterruptedListener;
> var session =
> _connection.CreateSession(AcknowledgementMode.AutoAcknowledge);
> var q = session.GetTopic("TopicName");
> var queue = session.CreateDurableConsumer(q, clientId, null,
> false);
> queue.Listener += msgsConsumer_Listener;
> _connection.Start();
> }
> static void msgsConsumer_Listener(IMessage message)
> {
> Console.WriteLine("Consumed: " + message.NMSMessageId);
>
> throw new InvalidOperationException("Maxxx", new
> Exception("Maxxx"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQNET-513) Exception message is not propagated in case of consumption failure
[
https://issues.apache.org/jira/browse/AMQNET-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014718#comment-15014718
]
ASF subversion and git services commented on AMQNET-513:
Commit 1715303 from [~tabish121] in branch 'ActiveMQ/trunk'
[ https://svn.apache.org/r1715303 ]
https://issues.apache.org/jira/browse/AMQNET-513
Preserve the rollback cause when poisoning a message.
> Exception message is not propagated in case of consumption failure
> --
>
> Key: AMQNET-513
> URL: https://issues.apache.org/jira/browse/AMQNET-513
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: NMS
>Affects Versions: 1.6.2, 1.7.0, 1.7.1
>Reporter: Maxim Cherednik
>Assignee: Jim Gomes
>
> After moving from version 1.6.2 to 1.7 we lost some functionality we were
> relying on.
> When we were failing to process message 6 times, it was moved to the
> Activemq.DLQ and the property dlqDeliveryFailureCause was filled with
> Exception message which was raised during the processing.
> After version update - the exception message is not propagated. This message
> instead:
> javax.jms.JMSException: Exceeded RedeliveryPolicy limit: 6
> Maybe there are other way to track which client failed to process message and
> why(exception message) ?
> Code sample:
> {code:title=Consumer.cs|borderStyle=solid}
> static void Consume()
> {
> var brokerUri = "";
> var clientId = "test";
> var connFactory = new ConnectionFactory(brokerUri, clientId);
> _connection = connFactory.CreateConnection();
> _connection.ExceptionListener += _connection_ExceptionListener;
> _connection.ConnectionResumedListener +=
> _connection_ConnectionResumedListener;
> _connection.ConnectionInterruptedListener +=
> _connection_ConnectionInterruptedListener;
> var session =
> _connection.CreateSession(AcknowledgementMode.AutoAcknowledge);
> var q = session.GetTopic("TopicName");
> var queue = session.CreateDurableConsumer(q, clientId, null,
> false);
> queue.Listener += msgsConsumer_Listener;
> _connection.Start();
> }
> static void msgsConsumer_Listener(IMessage message)
> {
> Console.WriteLine("Consumed: " + message.NMSMessageId);
>
> throw new InvalidOperationException("Maxxx", new
> Exception("Maxxx"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQNET-513) Exception message is not propagated in case of consumption failure
[
https://issues.apache.org/jira/browse/AMQNET-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014721#comment-15014721
]
ASF subversion and git services commented on AMQNET-513:
Commit 1715304 from [~tabish121] in branch 'ActiveMQ/branches/1.7.x'
[ https://svn.apache.org/r1715304 ]
https://issues.apache.org/jira/browse/AMQNET-513
Preserve the rollback cause when poisoning a message.
> Exception message is not propagated in case of consumption failure
> --
>
> Key: AMQNET-513
> URL: https://issues.apache.org/jira/browse/AMQNET-513
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: NMS
>Affects Versions: 1.6.2, 1.7.0, 1.7.1
>Reporter: Maxim Cherednik
>Assignee: Jim Gomes
>
> After moving from version 1.6.2 to 1.7 we lost some functionality we were
> relying on.
> When we were failing to process message 6 times, it was moved to the
> Activemq.DLQ and the property dlqDeliveryFailureCause was filled with
> Exception message which was raised during the processing.
> After version update - the exception message is not propagated. This message
> instead:
> javax.jms.JMSException: Exceeded RedeliveryPolicy limit: 6
> Maybe there are other way to track which client failed to process message and
> why(exception message) ?
> Code sample:
> {code:title=Consumer.cs|borderStyle=solid}
> static void Consume()
> {
> var brokerUri = "";
> var clientId = "test";
> var connFactory = new ConnectionFactory(brokerUri, clientId);
> _connection = connFactory.CreateConnection();
> _connection.ExceptionListener += _connection_ExceptionListener;
> _connection.ConnectionResumedListener +=
> _connection_ConnectionResumedListener;
> _connection.ConnectionInterruptedListener +=
> _connection_ConnectionInterruptedListener;
> var session =
> _connection.CreateSession(AcknowledgementMode.AutoAcknowledge);
> var q = session.GetTopic("TopicName");
> var queue = session.CreateDurableConsumer(q, clientId, null,
> false);
> queue.Listener += msgsConsumer_Listener;
> _connection.Start();
> }
> static void msgsConsumer_Listener(IMessage message)
> {
> Console.WriteLine("Consumed: " + message.NMSMessageId);
>
> throw new InvalidOperationException("Maxxx", new
> Exception("Maxxx"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6053) java.lang.ClassCastException while removing the inactive durable subscriber
[
https://issues.apache.org/jira/browse/AMQ-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013420#comment-15013420
]
Gary Tully commented on AMQ-6053:
-
I suspect this is a resolved by https://issues.apache.org/jira/browse/AMQ-5783
> java.lang.ClassCastException while removing the inactive durable subscriber
> ---
>
> Key: AMQ-6053
> URL: https://issues.apache.org/jira/browse/AMQ-6053
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, Message Store
>Affects Versions: 5.11.2
> Environment: ActiveMQ 5.11.2 , master slave with kahadb
>Reporter: Luigi Corollo
>
> Hi,
> we have a problem with the removing an inactive durable subscription after
> certain period of inactivity.
> It throws java.lang.ClassCastException.
> Broker Config:
> http://activemq.apache.org/schema/core;
> brokerName="localhost" dataDirectory="${activemq.data}" useJmx="true"
> schedulerSupport="true" offlineDurableSubscriberTimeout="6"
> offlineDurableSubscriberTaskSchedule="3">
> Log:
> ERROR | Failed to remove inactive durable subscriber
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.String
> at java.lang.String.compareTo(String.java:108)[:1.7.0_79]
> at java.util.Arrays.binarySearch0(Arrays.java:1481)[:1.7.0_79]
> at java.util.Arrays.binarySearch(Arrays.java:1423)[:1.7.0_79]
> at
> org.apache.activemq.store.kahadb.disk.index.BTreeNode.contains(BTreeNode.java:707)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.disk.index.BTreeIndex.containsKey(BTreeIndex.java:179)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase$MessageOrderIndex.getDeleteList(MessageDatabase.java:2951)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.removeAckLocationsForSub(MessageDatabase.java:2274)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.updateIndex(MessageDatabase.java:1482)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase$15.execute(MessageDatabase.java:1207)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.process(MessageDatabase.java:1204)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase$10.visit(MessageDatabase.java:1103)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.data.KahaSubscriptionCommand.visit(KahaSubscriptionCommand.java:187)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.process(MessageDatabase.java:1070)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.store(MessageDatabase.java:977)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.MessageDatabase.store(MessageDatabase.java:957)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.deleteSubscription(KahaDBStore.java:807)[activemq-kahadb-store-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.ProxyTopicMessageStore.deleteSubscription(ProxyTopicMessageStore.java:103)[activemq-broker-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.store.ProxyTopicMessageStore.deleteSubscription(ProxyTopicMessageStore.java:103)[activemq-broker-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.broker.region.Topic.deleteSubscription(Topic.java:201)[activemq-broker-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:213)[activemq-broker-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.broker.region.TopicRegion.doCleanup(TopicRegion.java:100)[activemq-broker-5.11.2.jar:5.11.2]
> at
> org.apache.activemq.broker.region.TopicRegion$1.run(TopicRegion.java:70)[activemq-broker-5.11.2.jar:5.11.2]
> at java.util.TimerThread.mainLoop(Timer.java:555)[:1.7.0_79]
> at java.util.TimerThread.run(Timer.java:505)[:1.7.0_79]
> Thanks,
> Luigi
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations
[
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015059#comment-15015059
]
Pablo Lozano commented on AMQ-6052:
---
I have found the issue that activates this problem.
{code:title=MBeanBridgeDestination.java|borderStyle=solid}
private Map destinationObjectNameMap = new
ConcurrentHashMap();
private Map
outboundDestinationViewMap = new ConcurrentHashMap();
private Map
inboundDestinationViewMap = new ConcurrentHashMap();
{code}
Both onOutboundMessage() and onInboundMessage() use the
destinationObjectNameMap to register the ObjectName of the
NetworkDestinationView. But each other overwrite their value when using a
duplex connection.
{code:title=MBeanBridgeDestination.java|borderStyle=solid}
public void onInboundMessage(Message message) {
destinationObjectNameMap.put(destination, objectName);
}
{code}
When running with the option to purge unactiveDestinationViews which by default
is active it will un-register from the MBeanServer the objectName that is found
on destinationObjectNameMap.remove(entry.getKey()); //ActiveMqDestination.
This happens on the method
purgeInactiveDestinationView(Map
map) which receives both outboundDestinationViewMap and
inboundDestinationViewMap.
Thus when running for outboundDestinationViewMap if the last registration of a
destination was actually of a inBound it will incorrectly delete the object
name of and inboundDestination insead of the one from outboundDestination.
I am working on a fix and submitting a patch for this issue.
> Network of brokers on duplex mode reports InstanceAlreadyExistsException on
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
> Issue Type: Bug
> Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
> Labels: jmx, networkBridge, networkConnector
>
> When using a network of brokers apparently on duplex with destinations which
> were already created on each MBeanBridgeDestination.onOutboundMessage() and
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it
> creates a massive amount of logs as this message repeats for every received
> message.
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
> uri="multicast://default" conduitSubscriptions="true" duplex="true" >
>
>
>
>
>
>
>
>
>
>
>
>
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
>
>
>
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"/>
> discoveryUri="multicast://default"
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"/>
> updateClusterClients="true"
> rebalanceClusterClients="true"
> updateClusterClientsOnRemove="true"/>
>
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN MBeanBridgeDestination
> - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException:
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at
>
[jira] [Comment Edited] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations
[
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015059#comment-15015059
]
Pablo Lozano edited comment on AMQ-6052 at 11/20/15 2:51 AM:
-
I have found the issue that activates this problem.
{code:title=MBeanBridgeDestination.java|borderStyle=solid}
private Map destinationObjectNameMap = new
ConcurrentHashMap();
private Map
outboundDestinationViewMap = new ConcurrentHashMap();
private Map
inboundDestinationViewMap = new ConcurrentHashMap();
{code}
Both onOutboundMessage() and onInboundMessage() use the
destinationObjectNameMap to register the ObjectName of the
NetworkDestinationView. But each other overwrite their value when using a
duplex connection.
{code:title=MBeanBridgeDestination.java|borderStyle=solid}
public void onInboundMessage(Message message) {
destinationObjectNameMap.put(destination, objectName);
}
{code}
When running with the option to purge unactiveDestinationViews which by default
is active it will un-register from the MBeanServer the objectName that is found
on destinationObjectNameMap.remove(entry.getKey()); //ActiveMqDestination.
This happens on the method
purgeInactiveDestinationView(Map
map) which receives both outboundDestinationViewMap and
inboundDestinationViewMap.
Thus when running for outboundDestinationViewMap if the last registration of a
destination was actually of a inBound it will incorrectly delete the object
name of and inboundDestination insead of the one from outboundDestination.
I am working on a fix and submitting a patch for this issue.
This seems to be related to AMQ-5265 which looks like it tried to fix the same
issue although apparently it was still present.
was (Author: altaflux):
I have found the issue that activates this problem.
{code:title=MBeanBridgeDestination.java|borderStyle=solid}
private Map destinationObjectNameMap = new
ConcurrentHashMap();
private Map
outboundDestinationViewMap = new ConcurrentHashMap();
private Map
inboundDestinationViewMap = new ConcurrentHashMap();
{code}
Both onOutboundMessage() and onInboundMessage() use the
destinationObjectNameMap to register the ObjectName of the
NetworkDestinationView. But each other overwrite their value when using a
duplex connection.
{code:title=MBeanBridgeDestination.java|borderStyle=solid}
public void onInboundMessage(Message message) {
destinationObjectNameMap.put(destination, objectName);
}
{code}
When running with the option to purge unactiveDestinationViews which by default
is active it will un-register from the MBeanServer the objectName that is found
on destinationObjectNameMap.remove(entry.getKey()); //ActiveMqDestination.
This happens on the method
purgeInactiveDestinationView(Map
map) which receives both outboundDestinationViewMap and
inboundDestinationViewMap.
Thus when running for outboundDestinationViewMap if the last registration of a
destination was actually of a inBound it will incorrectly delete the object
name of and inboundDestination insead of the one from outboundDestination.
I am working on a fix and submitting a patch for this issue.
> Network of brokers on duplex mode reports InstanceAlreadyExistsException on
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
> Issue Type: Bug
> Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
> Labels: jmx, networkBridge, networkConnector
>
> When using a network of brokers apparently on duplex with destinations which
> were already created on each MBeanBridgeDestination.onOutboundMessage() and
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it
> creates a massive amount of logs as this
[jira] [Commented] (ARTEMIS-223) XML Data import fails due to a ClassCastException
[
https://issues.apache.org/jira/browse/ARTEMIS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015120#comment-15015120
]
Justin Bertram commented on ARTEMIS-223:
This looks resolved to me. Can anyone confirm? [~clebertsuconic]?
> XML Data import fails due to a ClassCastException
> -
>
> Key: ARTEMIS-223
> URL: https://issues.apache.org/jira/browse/ARTEMIS-223
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Jeff Mesnil
>
> XmlDataImporter tries to cast a Long into an Integer at:
> {noformat}
> queueID = (Integer) ManagementHelper.getResult(reply);
> {noformat}
> The queueID is a long.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ARTEMIS-223) XML Data import fails due to a ClassCastException
[
https://issues.apache.org/jira/browse/ARTEMIS-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-223.
---
Resolution: Fixed
Fix Version/s: 1.1.0
> XML Data import fails due to a ClassCastException
> -
>
> Key: ARTEMIS-223
> URL: https://issues.apache.org/jira/browse/ARTEMIS-223
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Reporter: Jeff Mesnil
> Fix For: 1.1.0
>
>
> XmlDataImporter tries to cast a Long into an Integer at:
> {noformat}
> queueID = (Integer) ManagementHelper.getResult(reply);
> {noformat}
> The queueID is a long.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-6054) Durable subscriber cannot receive the existing messages after AMQ restarts
[ https://issues.apache.org/jira/browse/AMQ-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nevin Chen updated AMQ-6054: Attachment: (was: Web Console Snapshot.png) > Durable subscriber cannot receive the existing messages after AMQ restarts > -- > > Key: AMQ-6054 > URL: https://issues.apache.org/jira/browse/AMQ-6054 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.12.1 > Environment: Redhat Linux >Reporter: Nevin Chen > Attachments: Web Console Snapshot.png > > > *How to Reproduce* > 1. Make a durable subscription to a topic from a JMS client. > 2. Disconnect the JMS client. > 3. Send a message to the subscribed topic from another JMS client. > 4. Restart AMQ. > 5. When the duarable re-connects to AMQ, it cannot receive the message sent > in step 3. > *Cause Analysis* > The message is saved in the persistent store successfully. However, when the > message is marshalled by the class MessageMarshaller, the field > regionDestination is not marshalled and saved to persistent store. When the > message is recovered from persistent store after restart, the > regionDestination filed of Message is empty so it is unknown which topic this > message belongs to. > *Possible Cause* > In the method > org.apache.activemq.broker.region.Topic.activate(ConnectionContext context, > final DurableTopicSubscription subscription), the > subscription.isRecoveryRequired() check is always false. The message cannot > go to the subscription. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6054) Durable subscriber cannot receive the existing messages after AMQ restarts
[ https://issues.apache.org/jira/browse/AMQ-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nevin Chen updated AMQ-6054: Attachment: Web Console Snapshot.png AMQ web console snapshot before and after restart > Durable subscriber cannot receive the existing messages after AMQ restarts > -- > > Key: AMQ-6054 > URL: https://issues.apache.org/jira/browse/AMQ-6054 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.12.1 > Environment: Redhat Linux >Reporter: Nevin Chen > Attachments: Web Console Snapshot.png > > > *How to Reproduce* > 1. Make a durable subscription to a topic from a JMS client. > 2. Disconnect the JMS client. > 3. Send a message to the subscribed topic from another JMS client. > 4. Restart AMQ. > 5. When the duarable re-connects to AMQ, it cannot receive the message sent > in step 3. > *Cause Analysis* > The message is saved in the persistent store successfully. However, when the > message is marshalled by the class MessageMarshaller, the field > regionDestination is not marshalled and saved to persistent store. When the > message is recovered from persistent store after restart, the > regionDestination filed of Message is empty so it is unknown which topic this > message belongs to. > *Possible Cause* > In the method > org.apache.activemq.broker.region.Topic.activate(ConnectionContext context, > final DurableTopicSubscription subscription), the > subscription.isRecoveryRequired() check is always false. The message cannot > go to the subscription. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6054) Durable subscriber cannot receive the existing messages after AMQ restarts
Nevin Chen created AMQ-6054: --- Summary: Durable subscriber cannot receive the existing messages after AMQ restarts Key: AMQ-6054 URL: https://issues.apache.org/jira/browse/AMQ-6054 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.12.1 Environment: Redhat Linux Reporter: Nevin Chen *How to Reproduce* 1. Make a durable subscription to a topic from a JMS client. 2. Disconnect the JMS client. 3. Send a message to the subscribed topic from another JMS client. 4. Restart AMQ. 5. When the duarable re-connects to AMQ, it cannot receive the message sent in step 3. *Cause Analysis* The message is saved in the persistent store successfully. However, when the message is marshalled by the class MessageMarshaller, the field regionDestination is not marshalled and saved to persistent store. When the message is recovered from persistent store after restart, the regionDestination filed of Message is empty so it is unknown which topic this message belongs to. *Possible Cause* In the method org.apache.activemq.broker.region.Topic.activate(ConnectionContext context, final DurableTopicSubscription subscription), the subscription.isRecoveryRequired() check is always false. The message cannot go to the subscription. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (AMQ-6054) Durable subscriber cannot receive the existing messages after AMQ restarts
[ https://issues.apache.org/jira/browse/AMQ-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nevin Chen updated AMQ-6054: Comment: was deleted (was: Snapshot of AMQ web console before and after restart) > Durable subscriber cannot receive the existing messages after AMQ restarts > -- > > Key: AMQ-6054 > URL: https://issues.apache.org/jira/browse/AMQ-6054 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.12.1 > Environment: Redhat Linux >Reporter: Nevin Chen > Attachments: Web Console Snapshot.png > > > *How to Reproduce* > 1. Make a durable subscription to a topic from a JMS client. > 2. Disconnect the JMS client. > 3. Send a message to the subscribed topic from another JMS client. > 4. Restart AMQ. > 5. When the duarable re-connects to AMQ, it cannot receive the message sent > in step 3. > *Cause Analysis* > The message is saved in the persistent store successfully. However, when the > message is marshalled by the class MessageMarshaller, the field > regionDestination is not marshalled and saved to persistent store. When the > message is recovered from persistent store after restart, the > regionDestination filed of Message is empty so it is unknown which topic this > message belongs to. > *Possible Cause* > In the method > org.apache.activemq.broker.region.Topic.activate(ConnectionContext context, > final DurableTopicSubscription subscription), the > subscription.isRecoveryRequired() check is always false. The message cannot > go to the subscription. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6054) Durable subscriber cannot receive the existing messages after AMQ restarts
[ https://issues.apache.org/jira/browse/AMQ-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nevin Chen updated AMQ-6054: Attachment: Web Console Snapshot.png Snapshot of AMQ web console before and after restart > Durable subscriber cannot receive the existing messages after AMQ restarts > -- > > Key: AMQ-6054 > URL: https://issues.apache.org/jira/browse/AMQ-6054 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.12.1 > Environment: Redhat Linux >Reporter: Nevin Chen > Attachments: Web Console Snapshot.png > > > *How to Reproduce* > 1. Make a durable subscription to a topic from a JMS client. > 2. Disconnect the JMS client. > 3. Send a message to the subscribed topic from another JMS client. > 4. Restart AMQ. > 5. When the duarable re-connects to AMQ, it cannot receive the message sent > in step 3. > *Cause Analysis* > The message is saved in the persistent store successfully. However, when the > message is marshalled by the class MessageMarshaller, the field > regionDestination is not marshalled and saved to persistent store. When the > message is recovered from persistent store after restart, the > regionDestination filed of Message is empty so it is unknown which topic this > message belongs to. > *Possible Cause* > In the method > org.apache.activemq.broker.region.Topic.activate(ConnectionContext context, > final DurableTopicSubscription subscription), the > subscription.isRecoveryRequired() check is always false. The message cannot > go to the subscription. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6042) In ActiveMQMessageConsumer, always set rollback cause
[
https://issues.apache.org/jira/browse/AMQ-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Lichtin updated AMQ-6042:
Component/s: Broker
> In ActiveMQMessageConsumer, always set rollback cause
> -
>
> Key: AMQ-6042
> URL: https://issues.apache.org/jira/browse/AMQ-6042
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Reporter: Martin Lichtin
> Attachments: MessageListenerRedeliveryTest.java
>
>
> In ActiveMQMessageConsumer, currently the rollback cause is only set for the
> case auto- or individual-acks. However, it should also be set for the other
> cases, so that in the rollback() method it can be picked up when creating the
> poison ack.
> {code}
> if (isAutoAcknowledgeBatch() || isAutoAcknowledgeEach() ||
> session.isIndividualAcknowledge()) {
> // schedual redelivery and possible dlq processing
> md.setRollbackCause(e);
> rollback();
> } else {
> // Transacted or Client ack: Deliver the next message.
> afterMessageIsConsumed(md, false);
> }
> {code}
> I'd suggest to move md.setRollbackCause(e); to before the if().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ARTEMIS-305) colocated configuration can have mismatch of policies
Andy Taylor created ARTEMIS-305: --- Summary: colocated configuration can have mismatch of policies Key: ARTEMIS-305 URL: https://issues.apache.org/jira/browse/ARTEMIS-305 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Andy Taylor Assignee: Andy Taylor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-305) colocated configuration can have mismatch of policies
[ https://issues.apache.org/jira/browse/ARTEMIS-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013640#comment-15013640 ] Andy Taylor commented on ARTEMIS-305: - so if you create a replicated live but a shared store backup it should throw an exception > colocated configuration can have mismatch of policies > - > > Key: ARTEMIS-305 > URL: https://issues.apache.org/jira/browse/ARTEMIS-305 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Andy Taylor >Assignee: Andy Taylor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4155) Can't start Blueprint broker in Apache Karaf without having Spring JARs
[
https://issues.apache.org/jira/browse/AMQ-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon updated AMQ-4155:
Fix Version/s: (was: 5.13.0)
AGING_TO_DIE
> Can't start Blueprint broker in Apache Karaf without having Spring JARs
> ---
>
> Key: AMQ-4155
> URL: https://issues.apache.org/jira/browse/AMQ-4155
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Broker
>Affects Versions: 5.8.0
> Environment: Apache Karaf 2.3.0
>Reporter: Victor Antonovich
> Fix For: AGING_TO_DIE
>
>
> ActiveMQ 5.8-SNAPSHOT (compiled from trunk) is unable to start blueprint
> broker:
> {code}
> karaf@root> features:addurl
> mvn:org.apache.activemq/activemq-karaf/5.8-SNAPSHOT/xml/features
> karaf@root> features:install activemq activemq-blueprint
> karaf@root> activemq:create-broker -t blueprint
> Creating file: @|green
> /usr/java/apache-karaf-2.3.0/deploy/localhost-broker.xml|
> Default ActiveMQ Broker (localhost) configuration file created at:
> /usr/java/apache-karaf-2.3.0/deploy/localhost-broker.xml
> Please review the configuration and modify to suite your needs.
> 0
> karaf@root> la | grep localhost-broker
> [ 105] [Active ] [Failure ] [ 80] localhost-broker.xml (0.0.0)
> {code}
> Blueprint component doesn't start due to the {{NoClassDefFoundError}}:
> {code}
> 2012-11-02 16:26:24,702 | ERROR | rint Extender: 3 | BlueprintContainerImpl
> | container.BlueprintContainerImpl 375 | 7 -
> org.apache.aries.blueprint.core - 1.0.1 | Unable to start blueprint container
> for bundle localhost-broker.xml
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instanciating bean .component-2 of class class
> org.apache.activemq.xbean.XBeanBrokerService
> at
> org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:333)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_37]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_37]
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:646)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:353)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:252)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.run(DiscardableRunnable.java:48)[7:org.apache.aries.blueprint.core:1.0.1]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)[:1.6.0_37]
> at
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)[:1.6.0_37]
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)[:1.6.0_37]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)[:1.6.0_37]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:206)[:1.6.0_37]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_37]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662)[:1.6.0_37]
> Caused by: java.lang.NoClassDefFoundError:
> org/springframework/beans/BeansException
> at
> org.apache.activemq.xbean.XBeanBrokerService.(XBeanBrokerService.java:47)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)[:1.6.0_37]
> at
>
[jira] [Updated] (AMQ-4232) Kahadb does not allow to obtain count of used/free bytes in the storage
[ https://issues.apache.org/jira/browse/AMQ-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4232: Fix Version/s: (was: 5.13.0) NEEDS_REVIEW > Kahadb does not allow to obtain count of used/free bytes in the storage > --- > > Key: AMQ-4232 > URL: https://issues.apache.org/jira/browse/AMQ-4232 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.4.2, 5.7.0 > Environment: fedora15, ubuntu12.10; debian; probably independent >Reporter: Tomáš Martinec > Labels: hangs, kahadb, usage > Fix For: NEEDS_REVIEW > > Attachments: extending.kahadb.diff > > > The full story is user forum under title: > Activemq 5.4.2 hangs when the temp disk usage is used > TempUsage.retrieveUsage() always returns the size of the allocated storage > instead of the actual usage. I could not see what methods of kahadb returns > the needed information, so I extended the kahadb interface. > Note that this issue may cause other problems such as AMQ-4136. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4777) ActiveMQ broker silently fails to start in Karaf
[ https://issues.apache.org/jira/browse/AMQ-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4777: Fix Version/s: (was: 5.14.0) NEEDS_REVIEW > ActiveMQ broker silently fails to start in Karaf > > > Key: AMQ-4777 > URL: https://issues.apache.org/jira/browse/AMQ-4777 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 5.8.0 > Environment: Kubuntu 64-bit, Oracle JDK 7u40, Karaf 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré > Fix For: NEEDS_REVIEW > > > I have an application, deployed into Karaf. I install the activemq-broker > feature, and one of the app bundles uses ActiveMQConnectionFactory to get a > javax.jms.Connection instance and then uses the JMS API only (no other > ActiveMQ-specific APIs in use). I'll note that this bundle depends on another > bundle which uses the JMS API as well (no ActiveMQ imports there at all). The > application also depends on other karaf features such as cxf-dosgi. > ActiveMQ fails to start in a couple of ways, depending on the order of > installation of the features and app: > At first I got a LinkageError: > java.lang.LinkageError: loader constraint violation: when resolving method > "org.apache.activemq.ActiveMQConnectionFactory.createConne > ction()Ljavax/jms/Connection;" the class loader (instance of > org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current > class, com/myprojectgroup/bus/activemq/ActiveMQSession, and the class loader > (instance of org/eclipse/osgi/internal/baseadaptor/D > efaultClassLoader) for resolved class, > org/apache/activemq/ActiveMQConnectionFactory, have different Class objects > for the type Ljava > x/jms/Connection; used in the signature > at > com.myprojectgroup.bus.activemq.ActiveMQSession.createConnection(ActiveMQSession.java:38) > at > com.myprojectgroup.messaging.jms.Session.open(Session.java:70)[68:com.myprojectgroup.messaging:0.1.0.SNAPSHOT] > at > com.myprojectgroup.messaging.jms.Session$1.run(Session.java:108)[68:com.myprojectgroup.messaging:0.1.0.SNAPSHOT] > The only bundle that exports the javax.jms package is > org.apache.geronimo.specs.geronimo-jms_1.1_spec, though after further > investigation I found that the activemq-web-console bundle does have another > copy of it internally, which I think might be the cause of the conflict (it > does not import the package in the manifest, so I can't just remove the > package from the jar since it won't find the package exported by the > geronimo-jms bundle without a corresponding import declaration). The > activemq-osgi bundle has a DynamicImport-Package: *, which may further > complicate things. If it also had an explicit Import-Package directive for > the statically-linked classes it uses such as javax.jms ones, perhaps it > would go through the regular bundle classloading mechanism and avoid the > problem - I think it takes precedence over dynamic imports, though I'm not > sure). > Next, I played around with reordering the installation, and got to another > failure mode where there is no exception at all or any error in the logs, but > the broker simply fails to start silently. Perhaps this is also caused by > classloader issues but they are just occurring somewhere within ActiveMQ and > being silently ignored. This mode of failure I've managed to recreate easily: > On a fresh stock installation of Karaf 2.3.3, add two feature urls: > features:addurl mvn:org.apache.activemq/activemq-karaf/5.8.0/xml/features > mvn:org.apache.cxf.dosgi/cxf-dosgi/1.6-SNAPSHOT/xml/features > (you might need to add the apache snapshot repo to karaf for it to find the > dosgi snapshot feature) > And then install them in this order: > features:install -v cxf-dosgi-discovery-distributed activemq-broker > The broker will not be started, although the logs will have no errors. > Strangely, if you now uninstall the activemq-web-console bundle (not feature) > and restart karaf, the broker will start ok. Also if you install only > activemq-broker and not dosgi, it will start ok. > To simplify, I found that instead of the dosgi feature it's enough to install > and start the mvn:org.osgi/org.osgi.compendium/4.3.1 bundle before installing > activemq-broker to make it fail - this is from looking at the innards of the > dosgi feature, however if I remove this bundle from the feature the broker > still fails to start, so it's not the only bundle causing problems, but just > an example. > The only workaround I've found so far is to install everything, then > uninstall the activemq-web-console bundle and restart - then everything works > as it should. Strangely, not installing it in the first place
[jira] [Commented] (AMQ-4777) ActiveMQ broker silently fails to start in Karaf
[ https://issues.apache.org/jira/browse/AMQ-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013603#comment-15013603 ] Christopher L. Shannon commented on AMQ-4777: - Needs review now that Karaf is being updated to version 4. > ActiveMQ broker silently fails to start in Karaf > > > Key: AMQ-4777 > URL: https://issues.apache.org/jira/browse/AMQ-4777 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 5.8.0 > Environment: Kubuntu 64-bit, Oracle JDK 7u40, Karaf 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré > Fix For: NEEDS_REVIEW > > > I have an application, deployed into Karaf. I install the activemq-broker > feature, and one of the app bundles uses ActiveMQConnectionFactory to get a > javax.jms.Connection instance and then uses the JMS API only (no other > ActiveMQ-specific APIs in use). I'll note that this bundle depends on another > bundle which uses the JMS API as well (no ActiveMQ imports there at all). The > application also depends on other karaf features such as cxf-dosgi. > ActiveMQ fails to start in a couple of ways, depending on the order of > installation of the features and app: > At first I got a LinkageError: > java.lang.LinkageError: loader constraint violation: when resolving method > "org.apache.activemq.ActiveMQConnectionFactory.createConne > ction()Ljavax/jms/Connection;" the class loader (instance of > org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current > class, com/myprojectgroup/bus/activemq/ActiveMQSession, and the class loader > (instance of org/eclipse/osgi/internal/baseadaptor/D > efaultClassLoader) for resolved class, > org/apache/activemq/ActiveMQConnectionFactory, have different Class objects > for the type Ljava > x/jms/Connection; used in the signature > at > com.myprojectgroup.bus.activemq.ActiveMQSession.createConnection(ActiveMQSession.java:38) > at > com.myprojectgroup.messaging.jms.Session.open(Session.java:70)[68:com.myprojectgroup.messaging:0.1.0.SNAPSHOT] > at > com.myprojectgroup.messaging.jms.Session$1.run(Session.java:108)[68:com.myprojectgroup.messaging:0.1.0.SNAPSHOT] > The only bundle that exports the javax.jms package is > org.apache.geronimo.specs.geronimo-jms_1.1_spec, though after further > investigation I found that the activemq-web-console bundle does have another > copy of it internally, which I think might be the cause of the conflict (it > does not import the package in the manifest, so I can't just remove the > package from the jar since it won't find the package exported by the > geronimo-jms bundle without a corresponding import declaration). The > activemq-osgi bundle has a DynamicImport-Package: *, which may further > complicate things. If it also had an explicit Import-Package directive for > the statically-linked classes it uses such as javax.jms ones, perhaps it > would go through the regular bundle classloading mechanism and avoid the > problem - I think it takes precedence over dynamic imports, though I'm not > sure). > Next, I played around with reordering the installation, and got to another > failure mode where there is no exception at all or any error in the logs, but > the broker simply fails to start silently. Perhaps this is also caused by > classloader issues but they are just occurring somewhere within ActiveMQ and > being silently ignored. This mode of failure I've managed to recreate easily: > On a fresh stock installation of Karaf 2.3.3, add two feature urls: > features:addurl mvn:org.apache.activemq/activemq-karaf/5.8.0/xml/features > mvn:org.apache.cxf.dosgi/cxf-dosgi/1.6-SNAPSHOT/xml/features > (you might need to add the apache snapshot repo to karaf for it to find the > dosgi snapshot feature) > And then install them in this order: > features:install -v cxf-dosgi-discovery-distributed activemq-broker > The broker will not be started, although the logs will have no errors. > Strangely, if you now uninstall the activemq-web-console bundle (not feature) > and restart karaf, the broker will start ok. Also if you install only > activemq-broker and not dosgi, it will start ok. > To simplify, I found that instead of the dosgi feature it's enough to install > and start the mvn:org.osgi/org.osgi.compendium/4.3.1 bundle before installing > activemq-broker to make it fail - this is from looking at the innards of the > dosgi feature, however if I remove this bundle from the feature the broker > still fails to start, so it's not the only bundle causing problems, but just > an example. > The only workaround I've found so far is to install everything, then > uninstall the activemq-web-console bundle and restart - then everything works > as it should. Strangely, not
[jira] [Updated] (AMQ-4777) ActiveMQ broker silently fails to start in Karaf
[ https://issues.apache.org/jira/browse/AMQ-4777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4777: Fix Version/s: (was: 5.13.0) 5.14.0 > ActiveMQ broker silently fails to start in Karaf > > > Key: AMQ-4777 > URL: https://issues.apache.org/jira/browse/AMQ-4777 > Project: ActiveMQ > Issue Type: Bug > Components: OSGi/Karaf >Affects Versions: 5.8.0 > Environment: Kubuntu 64-bit, Oracle JDK 7u40, Karaf 2.3.3 >Reporter: Amichai Rothman >Assignee: Jean-Baptiste Onofré > Fix For: NEEDS_REVIEW > > > I have an application, deployed into Karaf. I install the activemq-broker > feature, and one of the app bundles uses ActiveMQConnectionFactory to get a > javax.jms.Connection instance and then uses the JMS API only (no other > ActiveMQ-specific APIs in use). I'll note that this bundle depends on another > bundle which uses the JMS API as well (no ActiveMQ imports there at all). The > application also depends on other karaf features such as cxf-dosgi. > ActiveMQ fails to start in a couple of ways, depending on the order of > installation of the features and app: > At first I got a LinkageError: > java.lang.LinkageError: loader constraint violation: when resolving method > "org.apache.activemq.ActiveMQConnectionFactory.createConne > ction()Ljavax/jms/Connection;" the class loader (instance of > org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current > class, com/myprojectgroup/bus/activemq/ActiveMQSession, and the class loader > (instance of org/eclipse/osgi/internal/baseadaptor/D > efaultClassLoader) for resolved class, > org/apache/activemq/ActiveMQConnectionFactory, have different Class objects > for the type Ljava > x/jms/Connection; used in the signature > at > com.myprojectgroup.bus.activemq.ActiveMQSession.createConnection(ActiveMQSession.java:38) > at > com.myprojectgroup.messaging.jms.Session.open(Session.java:70)[68:com.myprojectgroup.messaging:0.1.0.SNAPSHOT] > at > com.myprojectgroup.messaging.jms.Session$1.run(Session.java:108)[68:com.myprojectgroup.messaging:0.1.0.SNAPSHOT] > The only bundle that exports the javax.jms package is > org.apache.geronimo.specs.geronimo-jms_1.1_spec, though after further > investigation I found that the activemq-web-console bundle does have another > copy of it internally, which I think might be the cause of the conflict (it > does not import the package in the manifest, so I can't just remove the > package from the jar since it won't find the package exported by the > geronimo-jms bundle without a corresponding import declaration). The > activemq-osgi bundle has a DynamicImport-Package: *, which may further > complicate things. If it also had an explicit Import-Package directive for > the statically-linked classes it uses such as javax.jms ones, perhaps it > would go through the regular bundle classloading mechanism and avoid the > problem - I think it takes precedence over dynamic imports, though I'm not > sure). > Next, I played around with reordering the installation, and got to another > failure mode where there is no exception at all or any error in the logs, but > the broker simply fails to start silently. Perhaps this is also caused by > classloader issues but they are just occurring somewhere within ActiveMQ and > being silently ignored. This mode of failure I've managed to recreate easily: > On a fresh stock installation of Karaf 2.3.3, add two feature urls: > features:addurl mvn:org.apache.activemq/activemq-karaf/5.8.0/xml/features > mvn:org.apache.cxf.dosgi/cxf-dosgi/1.6-SNAPSHOT/xml/features > (you might need to add the apache snapshot repo to karaf for it to find the > dosgi snapshot feature) > And then install them in this order: > features:install -v cxf-dosgi-discovery-distributed activemq-broker > The broker will not be started, although the logs will have no errors. > Strangely, if you now uninstall the activemq-web-console bundle (not feature) > and restart karaf, the broker will start ok. Also if you install only > activemq-broker and not dosgi, it will start ok. > To simplify, I found that instead of the dosgi feature it's enough to install > and start the mvn:org.osgi/org.osgi.compendium/4.3.1 bundle before installing > activemq-broker to make it fail - this is from looking at the innards of the > dosgi feature, however if I remove this bundle from the feature the broker > still fails to start, so it's not the only bundle causing problems, but just > an example. > The only workaround I've found so far is to install everything, then > uninstall the activemq-web-console bundle and restart - then everything works > as it should. Strangely, not installing it in the first place doesn't
[jira] [Updated] (AMQ-4848) activemq:list - Should include the transport connectors and their urls
[ https://issues.apache.org/jira/browse/AMQ-4848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4848: Fix Version/s: (was: 5.13.0) 5.14.0 > activemq:list - Should include the transport connectors and their urls > -- > > Key: AMQ-4848 > URL: https://issues.apache.org/jira/browse/AMQ-4848 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Reporter: Claus Ibsen >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.14.0 > > > When using the karaf commands you can get a bit of information about the > broker. > But we need to output the transport connectors in use as well, so you can see > the types and url's, eg tcp://localhost:61616, and ampq:xxx and so forth. > We could add that to the list command that shows the broker names. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4761) Activemq console commands - Better human readable output
[ https://issues.apache.org/jira/browse/AMQ-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4761: Fix Version/s: (was: 5.13.0) 5.14.0 > Activemq console commands - Better human readable output > > > Key: AMQ-4761 > URL: https://issues.apache.org/jira/browse/AMQ-4761 > Project: ActiveMQ > Issue Type: Improvement > Components: OSGi/Karaf >Reporter: Claus Ibsen >Assignee: Jean-Baptiste Onofré > Fix For: 5.14.0 > > > The activemq commands which you can use from command line, and in karaf shell > outputs to the console. > Though the output is not well formatted / sorted etc. So it does look a bit > hard to read for humans. > We should improve this to make the output easier to read, by grouping related > information. And have nice tabular data where it makes sense. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4886) AMQ2149LevelDBTest hangs or fails frequently
[ https://issues.apache.org/jira/browse/AMQ-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4886: Fix Version/s: (was: 5.13.0) 5.14.0 > AMQ2149LevelDBTest hangs or fails frequently > > > Key: AMQ-4886 > URL: https://issues.apache.org/jira/browse/AMQ-4886 > Project: ActiveMQ > Issue Type: Bug >Reporter: Kevin Earls >Assignee: Kevin Earls > Fix For: 5.14.0 > > Attachments: AMQ2149LevelDBTest.stack > > > I'll update this as I get more information, but this test suite has multiple > cases that hang and timeout frequently > (testTopicTransactionalOrderWithRestart and testTopicOrderWithRestart seem to > do so most frequently.) > It can also hang in tearDown, which causes the whole suite to hang without > timing out, which can be a problem when run under Hudson or Jenkins. > I will attach a stack trace of the tearDown hang, and also update > AMQ2149Test to prevent this. I'm also going to update the test to use JUnit4 > and reduce the timeouts from 30 to 5 minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5321) activeMQ levelDB
[ https://issues.apache.org/jira/browse/AMQ-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-5321: Fix Version/s: (was: 5.13.0) 5.14.0 > activeMQ levelDB > - > > Key: AMQ-5321 > URL: https://issues.apache.org/jira/browse/AMQ-5321 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.10.0 > Environment: windows 7 >Reporter: Kevin > Fix For: 5.14.0 > > > https://issues.apache.org/jira/browse/AMQ-5257which was duplicated by > https://issues.apache.org/jira/browse/AMQ-5105. > claimed to be fixed in 5.11.0, but when I used the binaries of 5.11.0 from > unreleased > (https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.11-SNAPSHOT/) > , it is not fixed yet. > here is what I got: > PSHOT\bin\win32>activemq.bat > wrapper | --> Wrapper Started as Console > wrapper | Launching a JVM... > jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org > jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. > jvm 1| > jvm 1| Java Runtime: Oracle Corporation 1.7.0_67 C:\Program Files > (x86)\Java > \jre7 > jvm 1| Heap sizes: current=15872k free=12305k max=1013632k > jvm 1| JVM args: -Dactivemq.home=../.. -Dactivemq.base=../.. > -Djavax.net > .ssl.keyStorePassword=password -Djavax.net.ssl.trustStorePassword=password > -Djav > ax.net.ssl.keyStore=../../conf/broker.ks > -Djavax.net.ssl.trustStore=../../conf/b > roker.ts -Dcom.sun.management.jmxremote > -Dorg.apache.activemq.UseDedicatedTaskRu > nner=true -Djava.util.logging.config.file=logging.properties > -Dactivemq.conf=../ > ../conf -Dactivemq.data=../../data > -Djava.security.auth.login.config=../../conf/ > login.config -Xmx1024m -Djava.library.path=../../bin/win32 > -Dwrapper.key=7JJvTVF > 5VnXQi50z -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 > -Dwrapper.jvm.port.m > ax=31999 -Dwrapper.pid=6236 -Dwrapper.version=3.2.3 > -Dwrapper.native_library=wra > pper -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 > jvm 1| Extensions classpath: > jvm 1| > [..\..\lib,..\..\lib\camel,..\..\lib\optional,..\..\lib\web,..\..\l > ib\extra] > jvm 1| ACTIVEMQ_HOME: ..\.. > jvm 1| ACTIVEMQ_BASE: ..\.. > jvm 1| ACTIVEMQ_CONF: ..\..\conf > jvm 1| ACTIVEMQ_DATA: ..\..\data > jvm 1| Loading message broker from: xbean:activemq.xml > jvm 1| INFO | Refreshing > org.apache.activemq.xbean.XBeanBrokerFactory$1@193 > c227: startup date [Wed Aug 13 10:00:30 EDT 2014]; root of context hierarchy > jvm 1| INFO | Using Persistence Adapter: Replicated > LevelDB[C:\ActiveMQ\apa > che-activemq-5.11-20140808.003936-58-bin\apache-activemq-5.11-SNAPSHOT\bin\win32 > \..\..\data\leveldb, bosvsvm01:2181//activemq/leveldb-stores] > jvm 1| INFO | Starting StateChangeDispatcher > jvm 1| INFO | Client environment:zookeeper.version=3.4.5-1392090, built > on > 09/30/2012 17:52 GMT > jvm 1| INFO | Client environment:host.name=WMT-VS009.bost.local > jvm 1| INFO | Client environment:java.version=1.7.0_67 > jvm 1| INFO | Client environment:java.vendor=Oracle Corporation > jvm 1| INFO | Client environment:java.home=C:\Program Files > (x86)\Java\jre7 > jvm 1| INFO | Client > environment:java.class.path=../../bin/wrapper.jar;../. > ./bin/activemq.jar > jvm 1| INFO | Client environment:java.library.path=../../bin/win32 > jvm 1| INFO | Client > environment:java.io.tmpdir=C:\Users\george\AppData\Lo > cal\Temp\ > jvm 1| INFO | Client environment:java.compiler= > jvm 1| INFO | Client environment:os.name=Windows 7 > jvm 1| INFO | Client environment:os.arch=x86 > jvm 1| INFO | Client environment:os.version=6.1 > jvm 1| INFO | Client environment:user.name=george > jvm 1| INFO | Client environment:user.home=C:\Users\george > jvm 1| INFO | Client > environment:user.dir=C:\ActiveMQ\apache-activemq-5.11- > 20140808.003936-58-bin\apache-activemq-5.11-SNAPSHOT\bin\win32 > jvm 1| INFO | Initiating client connection, connectString=bosvsvm01:2181 > sessionTimeout=2000 > watcher=org.apache.activemq.leveldb.replicated.groups.ZKCli > ent@1fbdfd0 > jvm 1| WARN | SASL configuration failed: > javax.security.auth.login.LoginExc > eption: No JAAS configuration section named 'Client' was found in specified > JAAS > configuration file: '../../conf/login.config'. Will continue connection to > Zook > eeper server without SASL authentication, if Zookeeper server allows it. > jvm 1| INFO | Opening socket connection to server > brlvsvolap01.bluecrest.lo > cal/10.42.0.109:2181 > jvm 1| WARN | unprocessed event state: AuthFailed > jvm 1| INFO | Socket connection established to
[jira] [Updated] (AMQ-5321) activeMQ levelDB
[ https://issues.apache.org/jira/browse/AMQ-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-5321: Fix Version/s: (was: 5.14.0) NEEDS_REVIEW > activeMQ levelDB > - > > Key: AMQ-5321 > URL: https://issues.apache.org/jira/browse/AMQ-5321 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-leveldb-store >Affects Versions: 5.10.0 > Environment: windows 7 >Reporter: Kevin > Fix For: NEEDS_REVIEW > > > https://issues.apache.org/jira/browse/AMQ-5257which was duplicated by > https://issues.apache.org/jira/browse/AMQ-5105. > claimed to be fixed in 5.11.0, but when I used the binaries of 5.11.0 from > unreleased > (https://repository.apache.org/content/repositories/snapshots/org/apache/activemq/apache-activemq/5.11-SNAPSHOT/) > , it is not fixed yet. > here is what I got: > PSHOT\bin\win32>activemq.bat > wrapper | --> Wrapper Started as Console > wrapper | Launching a JVM... > jvm 1| Wrapper (Version 3.2.3) http://wrapper.tanukisoftware.org > jvm 1| Copyright 1999-2006 Tanuki Software, Inc. All Rights Reserved. > jvm 1| > jvm 1| Java Runtime: Oracle Corporation 1.7.0_67 C:\Program Files > (x86)\Java > \jre7 > jvm 1| Heap sizes: current=15872k free=12305k max=1013632k > jvm 1| JVM args: -Dactivemq.home=../.. -Dactivemq.base=../.. > -Djavax.net > .ssl.keyStorePassword=password -Djavax.net.ssl.trustStorePassword=password > -Djav > ax.net.ssl.keyStore=../../conf/broker.ks > -Djavax.net.ssl.trustStore=../../conf/b > roker.ts -Dcom.sun.management.jmxremote > -Dorg.apache.activemq.UseDedicatedTaskRu > nner=true -Djava.util.logging.config.file=logging.properties > -Dactivemq.conf=../ > ../conf -Dactivemq.data=../../data > -Djava.security.auth.login.config=../../conf/ > login.config -Xmx1024m -Djava.library.path=../../bin/win32 > -Dwrapper.key=7JJvTVF > 5VnXQi50z -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 > -Dwrapper.jvm.port.m > ax=31999 -Dwrapper.pid=6236 -Dwrapper.version=3.2.3 > -Dwrapper.native_library=wra > pper -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 > jvm 1| Extensions classpath: > jvm 1| > [..\..\lib,..\..\lib\camel,..\..\lib\optional,..\..\lib\web,..\..\l > ib\extra] > jvm 1| ACTIVEMQ_HOME: ..\.. > jvm 1| ACTIVEMQ_BASE: ..\.. > jvm 1| ACTIVEMQ_CONF: ..\..\conf > jvm 1| ACTIVEMQ_DATA: ..\..\data > jvm 1| Loading message broker from: xbean:activemq.xml > jvm 1| INFO | Refreshing > org.apache.activemq.xbean.XBeanBrokerFactory$1@193 > c227: startup date [Wed Aug 13 10:00:30 EDT 2014]; root of context hierarchy > jvm 1| INFO | Using Persistence Adapter: Replicated > LevelDB[C:\ActiveMQ\apa > che-activemq-5.11-20140808.003936-58-bin\apache-activemq-5.11-SNAPSHOT\bin\win32 > \..\..\data\leveldb, bosvsvm01:2181//activemq/leveldb-stores] > jvm 1| INFO | Starting StateChangeDispatcher > jvm 1| INFO | Client environment:zookeeper.version=3.4.5-1392090, built > on > 09/30/2012 17:52 GMT > jvm 1| INFO | Client environment:host.name=WMT-VS009.bost.local > jvm 1| INFO | Client environment:java.version=1.7.0_67 > jvm 1| INFO | Client environment:java.vendor=Oracle Corporation > jvm 1| INFO | Client environment:java.home=C:\Program Files > (x86)\Java\jre7 > jvm 1| INFO | Client > environment:java.class.path=../../bin/wrapper.jar;../. > ./bin/activemq.jar > jvm 1| INFO | Client environment:java.library.path=../../bin/win32 > jvm 1| INFO | Client > environment:java.io.tmpdir=C:\Users\george\AppData\Lo > cal\Temp\ > jvm 1| INFO | Client environment:java.compiler= > jvm 1| INFO | Client environment:os.name=Windows 7 > jvm 1| INFO | Client environment:os.arch=x86 > jvm 1| INFO | Client environment:os.version=6.1 > jvm 1| INFO | Client environment:user.name=george > jvm 1| INFO | Client environment:user.home=C:\Users\george > jvm 1| INFO | Client > environment:user.dir=C:\ActiveMQ\apache-activemq-5.11- > 20140808.003936-58-bin\apache-activemq-5.11-SNAPSHOT\bin\win32 > jvm 1| INFO | Initiating client connection, connectString=bosvsvm01:2181 > sessionTimeout=2000 > watcher=org.apache.activemq.leveldb.replicated.groups.ZKCli > ent@1fbdfd0 > jvm 1| WARN | SASL configuration failed: > javax.security.auth.login.LoginExc > eption: No JAAS configuration section named 'Client' was found in specified > JAAS > configuration file: '../../conf/login.config'. Will continue connection to > Zook > eeper server without SASL authentication, if Zookeeper server allows it. > jvm 1| INFO | Opening socket connection to server > brlvsvolap01.bluecrest.lo > cal/10.42.0.109:2181 > jvm 1| WARN | unprocessed event state: AuthFailed > jvm 1| INFO | Socket connection established to
[jira] [Updated] (AMQ-4886) AMQ2149LevelDBTest hangs or fails frequently
[ https://issues.apache.org/jira/browse/AMQ-4886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4886: Fix Version/s: (was: 5.14.0) NEEDS_REVIEW > AMQ2149LevelDBTest hangs or fails frequently > > > Key: AMQ-4886 > URL: https://issues.apache.org/jira/browse/AMQ-4886 > Project: ActiveMQ > Issue Type: Bug >Reporter: Kevin Earls >Assignee: Kevin Earls > Fix For: NEEDS_REVIEW > > Attachments: AMQ2149LevelDBTest.stack > > > I'll update this as I get more information, but this test suite has multiple > cases that hang and timeout frequently > (testTopicTransactionalOrderWithRestart and testTopicOrderWithRestart seem to > do so most frequently.) > It can also hang in tearDown, which causes the whole suite to hang without > timing out, which can be a problem when run under Hudson or Jenkins. > I will attach a stack trace of the tearDown hang, and also update > AMQ2149Test to prevent this. I'm also going to update the test to use JUnit4 > and reduce the timeouts from 30 to 5 minutes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5178) ActiveMQ Karaf - Add CLI command to create queue/topic
[ https://issues.apache.org/jira/browse/AMQ-5178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-5178: Fix Version/s: (was: 5.13.0) 5.14.0 > ActiveMQ Karaf - Add CLI command to create queue/topic > -- > > Key: AMQ-5178 > URL: https://issues.apache.org/jira/browse/AMQ-5178 > Project: ActiveMQ > Issue Type: New Feature > Components: OSGi/Karaf >Reporter: Claus Ibsen >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 5.14.0 > > > We have the activemq commands in Karaf where you can see some broker details. > It would be good to have a command to create a queue/topic which you can do > today using the web console. > For example people on SO have asked about this > http://stackoverflow.com/questions/23562106/how-to-add-new-queues-to-jboss-a-mq-using-the-command-line-console-interface -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4277) activemq-web - REST GET 204
[ https://issues.apache.org/jira/browse/AMQ-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4277: Fix Version/s: (was: 5.13.0) NEEDS_REVIEW > activemq-web - REST GET 204 > --- > > Key: AMQ-4277 > URL: https://issues.apache.org/jira/browse/AMQ-4277 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.7.0 > Environment: windows 7 and windows xp >Reporter: Helen Huang > Fix For: NEEDS_REVIEW > > Attachments: AMQ4277TestPatch.txt, RestTest.java > > > Using 5.7 REST API I can GET a message from a topic but if a new message is > POSTed to that same topic before the GET has been reissued (less than 20ms > behind the POST and using the same session as the previous GET) the GET will > timeout with a 204 and does not retrieve the message. This may be as designed > for topics (queues are not an option) but I am just looking for confirmation. > I assumed the first GET would have provided a topic subscription and the > broker would hold a topic message for which there is a subscriber for longer > than 20ms? This is not a stress test and is recreated with a simple producer > and a separate consumer usually within the first couple of message exchanges. > It has been noticed that when the topic message is POSTed without an > outstanding GET to receive it, the following exception is logged: > 2013-01-22 01:09:37,484 | DEBUG | Async client internal exception occurred > with no exception listener registered: java.lang.IllegalStateException: > DISPATCHED,initial | org.apache.activemq.ActiveMQConnection | ActiveMQ > Session Task-1 > java.lang.IllegalStateException: DISPATCHED,initial > at > org.eclipse.jetty.server.AsyncContinuation.dispatch(AsyncContinuation.java:408) > > at > org.eclipse.jetty.server.AsyncContinuation.resume(AsyncContinuation.java:815) > at > org.apache.activemq.web.MessageServlet$Listener.onMessageAvailable(MessageServlet.java:409) > > at > org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1343) > > at > org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131) > > at > org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202) > > at > org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:129) > > at > org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:47) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > > at java.lang.Thread.run(Thread.java:722) > > Are there any configuration modifications available to have the topic > messages retained for at least 1 second? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-4244) RA activation spec maxMessagesPerSessions property not honored.
[ https://issues.apache.org/jira/browse/AMQ-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon updated AMQ-4244: Fix Version/s: (was: 5.13.0) NEEDS_REVIEW > RA activation spec maxMessagesPerSessions property not honored. > --- > > Key: AMQ-4244 > URL: https://issues.apache.org/jira/browse/AMQ-4244 > Project: ActiveMQ > Issue Type: Bug > Components: JCA Container >Affects Versions: 5.7.0 >Reporter: Hiram Chirino > Fix For: NEEDS_REVIEW > > > Seems like it was supposed to control prefetching, right now it has no > effect. see: > https://github.com/apache/activemq/blob/trunk/activemq-ra/src/main/java/org/apache/activemq/ra/ActiveMQEndpointWorker.java#L170 > Connection settings are the only way to configure the prefetching when used > in a resource adapter now. > Would be nice if a the maxMessagesPerSessions setting could be renamed to > something simpler like prefetchSize. And IF set, then it overrides the > connection defaults. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
