[jira] [Updated] (ARTEMIS-309) Upgrade commons-collections
[ https://issues.apache.org/jira/browse/ARTEMIS-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated ARTEMIS-309: Fix Version/s: 1.1.1 > Upgrade commons-collections > --- > > Key: ARTEMIS-309 > URL: https://issues.apache.org/jira/browse/ARTEMIS-309 > Project: ActiveMQ Artemis > Issue Type: Task >Affects Versions: 1.1.0 >Reporter: Claus Ibsen >Priority: Blocker > Fix For: 1.2.0, 1.1.1 > > > Noticed that we use 3.2.1 version of commons collection > https://github.com/apache/activemq-artemis/blob/master/artemis-features/src/main/resources/features.xml#L38 > It should be upgraded to 3.2.2 due the security issue that is fixed in the > 3.2.2 release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ARTEMIS-310) Upgrade jolokia to 1.3.2
[ https://issues.apache.org/jira/browse/ARTEMIS-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated ARTEMIS-310: Fix Version/s: (was: 1.1.0) 1.2.0 > Upgrade jolokia to 1.3.2 > > > Key: ARTEMIS-310 > URL: https://issues.apache.org/jira/browse/ARTEMIS-310 > Project: ActiveMQ Artemis > Issue Type: Task >Reporter: Claus Ibsen >Priority: Minor > Fix For: 1.2.0 > > > We should upgrade to jolokia 1.3.2 > https://github.com/apache/activemq-artemis/blob/master/pom.xml#L467 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-6076) [DISCUSS] How to solve the problem of two ActiveMQ synchronous exception?
[ https://issues.apache.org/jira/browse/AMQ-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenkw updated AMQ-6076: Summary: [DISCUSS] How to solve the problem of two ActiveMQ synchronous exception? (was: At some point, two MQ server synchronization abnormal?) > [DISCUSS] How to solve the problem of two ActiveMQ synchronous exception? > - > > Key: AMQ-6076 > URL: https://issues.apache.org/jira/browse/AMQ-6076 > Project: ActiveMQ > Issue Type: Bug > Components: activemq-camel >Affects Versions: 5.12.1 > Environment: Configuration： > > password="admin"/> > > discoveryUri="multicast://default" /> >Reporter: chenkw > > MQ1: > INFO | jvm 1| 2015/11/30 20:33:26 | INFO | Establishing network > connection from vm://localhost?async=false to tcp://MQ-3:61616 > INFO | jvm 1| 2015/11/30 20:33:26 | WARN | Failed to add Connection > localhost->ITP_MQ3-64055-1448551657492-114804:1 due to > javax.jms.InvalidClientIDException: Broker: localhost - Client: > NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 > INFO | jvm 1| 2015/11/30 20:33:26 | INFO | Network connection between > vm://localhost#109468 and tcp://MQ-3/192.168.200.35:61616@57666 shutdown due > to a local error: javax.jms.InvalidClientIDException: Broker: localhost - > Client: NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 > INFO | jvm 1| 2015/11/30 20:33:26 | INFO | localhost bridge to ITP_MQ3 > stopped > INFO | jvm 1| 2015/11/30 20:33:32 | INFO | Establishing network > connection from vm://localhost?async=false to tcp://MQ-3:61616 > INFO | jvm 1| 2015/11/30 20:33:32 | WARN | Failed to add Connection > localhost->ITP_MQ3-64055-1448551657492-114806:1 due to > javax.jms.InvalidClientIDException: Broker: localhost - Client: > NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 > INFO | jvm 1| 2015/11/30 20:33:32 | INFO | Network connection between > vm://localhost#109470 and tcp://MQ-3/192.168.200.35:61616@57667 shutdown due > to a local error: javax.jms.InvalidClientIDException: Broker: localhost - > Client: NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 > INFO | jvm 1| 2015/11/30 20:33:32 | INFO | localhost bridge to ITP_MQ3 > stopped > MQ3: > INFO | jvm 1| 2015/11/30 18:58:53 | INFO | Establishing network > connection from vm://ITP_MQ3?async=false to tcp://MQ-1:61616 > INFO | jvm 1| 2015/11/30 18:58:53 | WARN | Failed to add Connection > ITP_MQ3->localhost-65195-1448550819638-112421:1 due to > javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: > NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 > INFO | jvm 1| 2015/11/30 18:58:53 | INFO | Network connection between > vm://ITP_MQ3#107218 and tcp://MQ-1/192.168.200.13:61616@57199 shutdown due to > a local error: javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: > NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 > INFO | jvm 1| 2015/11/30 18:58:53 | INFO | ITP_MQ3 bridge to localhost > stopped > INFO | jvm 1| 2015/11/30 18:58:58 | INFO | Establishing network > connection from vm://ITP_MQ3?async=false to tcp://MQ-1:61616 > INFO | jvm 1| 2015/11/30 18:58:58 | WARN | Failed to add Connection > ITP_MQ3->localhost-65195-1448550819638-112423:1 due to > javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: > NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 > INFO | jvm 1| 2015/11/30 18:58:58 | INFO | Network connection between > vm://ITP_MQ3#107220 and tcp://MQ-1/192.168.200.13:61616@57200 shutdown due to > a local error: javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: > NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 > INFO | jvm 1| 2015/11/30 18:58:58 | INFO | ITP_MQ3 bridge to localhost > stopped -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic
[
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-303.
Resolution: Fixed
> listDurableSubscriptionsAsJson fails if there is a durable subscription on a
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException:
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> java.security.AccessController.doPrivileged(Native Method)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> javax.security.auth.Subject.doAs(Subject.java:422)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4)
[jira] [Commented] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic
[
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047537#comment-15047537
]
ASF subversion and git services commented on ARTEMIS-303:
-
Commit 831eabfc738ef852efa10a88a880c37303362859 in activemq-artemis's branch
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=831eabf ]
ARTEMIS-303 listing subs fails for JMS2 shared sub
> listDurableSubscriptionsAsJson fails if there is a durable subscription on a
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException:
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> java.security.AccessController.doPrivileged(Native Method)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> javax.security.auth.Subject.doAs(Subject.java:422)
> 12:43:27,238 ERROR [stderr] (pool-3-thr
[jira] [Commented] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic
[
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047539#comment-15047539
]
ASF GitHub Bot commented on ARTEMIS-303:
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/259
> listDurableSubscriptionsAsJson fails if there is a durable subscription on a
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException:
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> java.security.AccessController.doPrivileged(Native Method)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> javax.security.auth.Subject.doAs(Subject.java:422)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.
[jira] [Commented] (AMQ-6082) StoreOpenWireVersion is not properly set on KahaDB index corruption recovery
[
https://issues.apache.org/jira/browse/AMQ-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047408#comment-15047408
]
ASF subversion and git services commented on AMQ-6082:
--
Commit 785041d20f3093b8a22a4428c91514534483fd8f in activemq's branch
refs/heads/activemq-5.13.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=785041d ]
https://issues.apache.org/jira/browse/AMQ-6082
Propertly re-setting the storeOpenWireVersion from the BrokerService
on the KahaDB Metadata if a corrupted index is detected and the
Metadata has to be recreated.
(cherry picked from commit 7a7c70ad7524594339c4388b897fa1eac6988928)
> StoreOpenWireVersion is not properly set on KahaDB index corruption recovery
>
>
> Key: AMQ-6082
> URL: https://issues.apache.org/jira/browse/AMQ-6082
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
>
> The BrokerService has a property called {{storeOpenWireVersion}} to set the
> specified OpenWire version to use for the store.
> On start up, KahaDB will first set this value as the OpenWire version used in
> the index metadata in memory, and then if it detects a different version when
> reading in an existing index, it will reset the the version to the version
> that was detected.
> The problem is that if a corrupted index is detected during the reading of
> the index, the metadata is recreated in the catch block but the
> storeOpenWireVersion that was set on the BrokerService is never copied back
> to the new Metadata. This happens in the open() method of MessageDatabase.
> This causes marshalling errors because the index will now be recreated with
> the default OpenWire version instead of the actual version that was set on
> the broker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (AMQ-6082) StoreOpenWireVersion is not properly set on KahaDB index corruption recovery
[
https://issues.apache.org/jira/browse/AMQ-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher L. Shannon resolved AMQ-6082.
-
Resolution: Fixed
Fix Version/s: 5.14.0
5.13.1
Fix and test applied. KahaDB will now properly reset the configured version on
the new Metadata after a detected corruption.
> StoreOpenWireVersion is not properly set on KahaDB index corruption recovery
>
>
> Key: AMQ-6082
> URL: https://issues.apache.org/jira/browse/AMQ-6082
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 5.13.1, 5.14.0
>
>
> The BrokerService has a property called {{storeOpenWireVersion}} to set the
> specified OpenWire version to use for the store.
> On start up, KahaDB will first set this value as the OpenWire version used in
> the index metadata in memory, and then if it detects a different version when
> reading in an existing index, it will reset the the version to the version
> that was detected.
> The problem is that if a corrupted index is detected during the reading of
> the index, the metadata is recreated in the catch block but the
> storeOpenWireVersion that was set on the BrokerService is never copied back
> to the new Metadata. This happens in the open() method of MessageDatabase.
> This causes marshalling errors because the index will now be recreated with
> the default OpenWire version instead of the actual version that was set on
> the broker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6082) StoreOpenWireVersion is not properly set on KahaDB index corruption recovery
[
https://issues.apache.org/jira/browse/AMQ-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047398#comment-15047398
]
ASF subversion and git services commented on AMQ-6082:
--
Commit 7a7c70ad7524594339c4388b897fa1eac6988928 in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=7a7c70a ]
https://issues.apache.org/jira/browse/AMQ-6082
Propertly re-setting the storeOpenWireVersion from the BrokerService
on the KahaDB Metadata if a corrupted index is detected and the
Metadata has to be recreated.
> StoreOpenWireVersion is not properly set on KahaDB index corruption recovery
>
>
> Key: AMQ-6082
> URL: https://issues.apache.org/jira/browse/AMQ-6082
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, KahaDB
>Affects Versions: 5.13.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>
> The BrokerService has a property called {{storeOpenWireVersion}} to set the
> specified OpenWire version to use for the store.
> On start up, KahaDB will first set this value as the OpenWire version used in
> the index metadata in memory, and then if it detects a different version when
> reading in an existing index, it will reset the the version to the version
> that was detected.
> The problem is that if a corrupted index is detected during the reading of
> the index, the metadata is recreated in the catch block but the
> storeOpenWireVersion that was set on the BrokerService is never copied back
> to the new Metadata. This happens in the open() method of MessageDatabase.
> This causes marshalling errors because the index will now be recreated with
> the default OpenWire version instead of the actual version that was set on
> the broker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-6082) StoreOpenWireVersion is not properly set on KahaDB index corruption recovery
Christopher L. Shannon created AMQ-6082:
---
Summary: StoreOpenWireVersion is not properly set on KahaDB index
corruption recovery
Key: AMQ-6082
URL: https://issues.apache.org/jira/browse/AMQ-6082
Project: ActiveMQ
Issue Type: Bug
Components: Broker, KahaDB
Affects Versions: 5.13.0
Reporter: Christopher L. Shannon
Assignee: Christopher L. Shannon
The BrokerService has a property called {{storeOpenWireVersion}} to set the
specified OpenWire version to use for the store.
On start up, KahaDB will first set this value as the OpenWire version used in
the index metadata in memory, and then if it detects a different version when
reading in an existing index, it will reset the the version to the version that
was detected.
The problem is that if a corrupted index is detected during the reading of the
index, the metadata is recreated in the catch block but the
storeOpenWireVersion that was set on the BrokerService is never copied back to
the new Metadata. This happens in the open() method of MessageDatabase.
This causes marshalling errors because the index will now be recreated with the
default OpenWire version instead of the actual version that was set on the
broker.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ARTEMIS-314) Support JCA inflow connection rebalancing when reconnectAttempts == -1
[ https://issues.apache.org/jira/browse/ARTEMIS-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-314. Resolution: Fixed > Support JCA inflow connection rebalancing when reconnectAttempts == -1 > -- > > Key: ARTEMIS-314 > URL: https://issues.apache.org/jira/browse/ARTEMIS-314 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 1.1.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 1.1.1 > > > Currently the re-balancing implementation will only rebalance when the > underlying connection stops trying to reconnect. If reconnectAttempts == -1 > then rebalancing will never occur. This should be changed so that > rebalancing occurs even if reconnectAttempts == -1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic
[
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047293#comment-15047293
]
ASF GitHub Bot commented on ARTEMIS-303:
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/259
ARTEMIS-303 listing subs fails for JMS2 shared sub
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-303
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/259.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 #259
commit c40b83c93fb237e374e5a5f19fb898a56af33a6e
Author: jbertram
Date: 2015-12-08T19:09:26Z
ARTEMIS-303 listing subs fails for JMS2 shared sub
> listDurableSubscriptionsAsJson fails if there is a durable subscription on a
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException:
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Intercept
[jira] [Commented] (AMQ-6013) Restrict classes that can be serialized in ObjectMessages
[ https://issues.apache.org/jira/browse/AMQ-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047070#comment-15047070 ] Dejan Bosanac commented on AMQ-6013: This issue is related to CVE-2015-5254 as described at http://activemq.apache.org/security-advisories.data/CVE-2015-5254-announcement.txt > Restrict classes that can be serialized in ObjectMessages > - > > Key: AMQ-6013 > URL: https://issues.apache.org/jira/browse/AMQ-6013 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.11.3, 5.13.0 > > > At some points we do (de)serialization of JMS Object messages inside the > broker (HTTP, Stomp, Web Console, ...). We need to restrict classes that can > be serialized in this way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic
[
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047032#comment-15047032
]
Justin Bertram commented on ARTEMIS-303:
Thanks. I've reproduced the exception, and I'm investigating further.
> listDurableSubscriptionsAsJson fails if there is a durable subscription on a
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException:
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at
> java.security.AccessController.doPrivileged(Native Method)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> javax.security.auth.Subject.doAs(Subject.java:422)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at
> org.jboss.as.jmx.ServerInterceptorFactory$Inter
[jira] [Created] (AMQ-6081) Tooling to look inside a kahadb
Christian Schneider created AMQ-6081: Summary: Tooling to look inside a kahadb Key: AMQ-6081 URL: https://issues.apache.org/jira/browse/AMQ-6081 Project: ActiveMQ Issue Type: New Feature Components: KahaDB Affects Versions: 5.13.0 Reporter: Christian Schneider Fix For: 5.x Sometimes it would help to be able to look into the kahadb while activemq is not running. For example we had an ever growing kahadb while all messages seemed to be consumed. In this case it would be interesting what activemq is storing there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5454) Topic messages can't be sent to DLQ, because region destination value is null
[ https://issues.apache.org/jira/browse/AMQ-5454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046929#comment-15046929 ] ASF subversion and git services commented on AMQ-5454: -- Commit c67590104b0836906b0701c641eabb6e66989da6 in activemq's branch refs/heads/activemq-5.13.x from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=c675901 ] https://issues.apache.org/jira/browse/AMQ-5454 https://issues.apache.org/jira/browse/AMQ-6070 - in the case of duplicates from the store the regiondestination was not set (cherry picked from commit 88ec9dad9dc47790a3fc4e0f5ad939ea5530dad7) > Topic messages can't be sent to DLQ, because region destination value is null > - > > Key: AMQ-5454 > URL: https://issues.apache.org/jira/browse/AMQ-5454 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.10.0 > Environment: published and subscriber connections created via Spring > xml configuration file. > The messages are persistent (Durable subscription) >Reporter: Gustavo Lara >Assignee: Gary Tully > Fix For: 5.14.0 > > > When Topic.send is executed, the message is stored with the proper region > destination. > When RegionBroker.sendToDeadLetterQueue is called, for some reason the call > to MessageReference node.getRegionDestinations (ln 728) is null. > MessageReference is an instance of ActiveMQBlobMessage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6070) originalDestination property of advisory messages set to message id in error
[ https://issues.apache.org/jira/browse/AMQ-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046928#comment-15046928 ] ASF subversion and git services commented on AMQ-6070: -- Commit 558dcc0479bc355fd5b2ecf0d62d1caefbb05fce in activemq's branch refs/heads/activemq-5.13.x from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=558dcc0 ] https://issues.apache.org/jira/browse/AMQ-6070 - rework for virtual topic case, use the destination from the transient region destination rather than the message, such that consumer queue advisories work for delivered etc (cherry picked from commit 179dc3acb28a8a7fc3c1eddf6c6ac54fe49836a5) > originalDestination property of advisory messages set to message id in error > > > Key: AMQ-6070 > URL: https://issues.apache.org/jira/browse/AMQ-6070 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 5.12.2, 5.13.1, 5.14.0 > > > The discarded/consumed/delivered advisories have the messageid as the value > of the property key originalDestination in error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6070) originalDestination property of advisory messages set to message id in error
[ https://issues.apache.org/jira/browse/AMQ-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046930#comment-15046930 ] ASF subversion and git services commented on AMQ-6070: -- Commit c67590104b0836906b0701c641eabb6e66989da6 in activemq's branch refs/heads/activemq-5.13.x from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=c675901 ] https://issues.apache.org/jira/browse/AMQ-5454 https://issues.apache.org/jira/browse/AMQ-6070 - in the case of duplicates from the store the regiondestination was not set (cherry picked from commit 88ec9dad9dc47790a3fc4e0f5ad939ea5530dad7) > originalDestination property of advisory messages set to message id in error > > > Key: AMQ-6070 > URL: https://issues.apache.org/jira/browse/AMQ-6070 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 5.12.2, 5.13.1, 5.14.0 > > > The discarded/consumed/delivered advisories have the messageid as the value > of the property key originalDestination in error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-6080) Fix typos relating to AMQ-6027
[ https://issues.apache.org/jira/browse/AMQ-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon resolved AMQ-6080. - Resolution: Fixed Fix Version/s: 5.14.0 5.13.1 > Fix typos relating to AMQ-6027 > -- > > Key: AMQ-6080 > URL: https://issues.apache.org/jira/browse/AMQ-6080 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.13.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 5.13.1, 5.14.0 > > > I found a couple of minor typos from AMQ-6027 that I am fixing in a patch > release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6080) Fix typos relating to AMQ-6027
[ https://issues.apache.org/jira/browse/AMQ-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046844#comment-15046844 ] ASF subversion and git services commented on AMQ-6080: -- Commit 1ebfa9ade2a3b64b76dfb53e51d550271bea3bf2 in activemq's branch refs/heads/activemq-5.13.x from [~cshannon] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=1ebfa9a ] https://issues.apache.org/jira/browse/AMQ-6080 fixing typos (cherry picked from commit 5772e7bed88198f57fabb08c2f48a1de68dea72c) > Fix typos relating to AMQ-6027 > -- > > Key: AMQ-6080 > URL: https://issues.apache.org/jira/browse/AMQ-6080 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.13.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 5.13.1, 5.14.0 > > > I found a couple of minor typos from AMQ-6027 that I am fixing in a patch > release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6080) Fix typos relating to AMQ-6027
[ https://issues.apache.org/jira/browse/AMQ-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046843#comment-15046843 ] ASF subversion and git services commented on AMQ-6080: -- Commit 5772e7bed88198f57fabb08c2f48a1de68dea72c in activemq's branch refs/heads/master from [~cshannon] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=5772e7b ] https://issues.apache.org/jira/browse/AMQ-6080 fixing typos > Fix typos relating to AMQ-6027 > -- > > Key: AMQ-6080 > URL: https://issues.apache.org/jira/browse/AMQ-6080 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.13.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > > I found a couple of minor typos from AMQ-6027 that I am fixing in a patch > release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6080) Fix typos relating to AMQ-6027
Christopher L. Shannon created AMQ-6080: --- Summary: Fix typos relating to AMQ-6027 Key: AMQ-6080 URL: https://issues.apache.org/jira/browse/AMQ-6080 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.13.0 Reporter: Christopher L. Shannon Assignee: Christopher L. Shannon Priority: Minor I found a couple of minor typos from AMQ-6027 that I am fixing in a patch release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6079) Replace log4j.properties with log4j.xml
Laure Lussac created AMQ-6079: - Summary: Replace log4j.properties with log4j.xml Key: AMQ-6079 URL: https://issues.apache.org/jira/browse/AMQ-6079 Project: ActiveMQ Issue Type: Improvement Reporter: Laure Lussac Priority: Minor Certain log4j features are not configurable via the log4j.properties file. For this reason, it could be converted to a XML file to configure log4j. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQ-6078) queues
[ https://issues.apache.org/jira/browse/AMQ-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher L. Shannon closed AMQ-6078. --- Resolution: Incomplete > queues > -- > > Key: AMQ-6078 > URL: https://issues.apache.org/jira/browse/AMQ-6078 > Project: ActiveMQ > Issue Type: Bug >Reporter: vasudevan rao > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6078) queues
vasudevan rao created AMQ-6078: -- Summary: queues Key: AMQ-6078 URL: https://issues.apache.org/jira/browse/AMQ-6078 Project: ActiveMQ Issue Type: Bug Reporter: vasudevan rao -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5486) Thread synchronization overhead is unexpectedly high
[ https://issues.apache.org/jira/browse/AMQ-5486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046777#comment-15046777 ] Gary Tully commented on AMQ-5486: - that looks like a sensible enhancement. my only comment would be the current MAX_INT default appears to be being replaced with 10, as the default value when the property is referenced. I guess it would be best to retain the current defaults. > Thread synchronization overhead is unexpectedly high > > > Key: AMQ-5486 > URL: https://issues.apache.org/jira/browse/AMQ-5486 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.9.1 > Environment: UbuntuServer 12.04 x86_64, Linux Kernel 3.20.23, OpenJDK > 1.7.0_51 64-Bit Server VM, Xms 2G, Xms 8G, CPU: E5-2620 v2 X 2, 64 GB RAM >Reporter: Benjamin Huang > Fix For: NEEDS_REVIEW > > Attachments: Method_Statistics.html, Monitor_History.zip, > Monitor_Usage_Statistics.html, monitor_usage_stats.png, > nio_worker_blocked_1.png, nio_worker_blocked_2.png, > nio_worker_blocked_frequently.png, tunable_threadpool_options.patch > > > There's about 20 topics with virtual topic enabled, hundreds of > comsumers/producers connected to MQ on NIO transport connector. During the > run there're about 12000 msg flow in per second, not a very high rate, but > ActiveMQ consumes a lot of CPU resource (about 600%~1000%). To find out > what's the most CPU consuming code path, I use JProfiler to dig into the > process. > Among all the NIO worker threads, most of them were frequently blocked and > did a little job between the 'unblocked' time. While they're expected spend > most of their time slices on waiting for work item and processed them. > !nio_worker_blocked_frequently.png! > After reviewing the monitor usage history and stats, I think these NIO > workers were competing fiercely with each other on executing a synchronized > method (DestinationMap::get), which is also the most hot spot in the program > . I also notice that the caller AbstractRegion::getDestinations acquires a > read lock before calling it, so I guess this could be a left out, read lock > is the actual lock type required here. > !monitor_usage_stats.png! > !nio_worker_blocked_1.png! > !nio_worker_blocked_2.png! > It's too difficult for me to list all critical sections between NIO workers, > or between NIO workers and BrokerService which adds up to the overall > synchronize overhead. So I attach the relevant info, with the hope of finding > a complete solution to this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (AMQ-5454) Topic messages can't be sent to DLQ, because region destination value is null
[ https://issues.apache.org/jira/browse/AMQ-5454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-5454. - Resolution: Fixed Assignee: Gary Tully Fix Version/s: (was: NEEDS_REVIEW) 5.14.0 I think I found the problem. It would be great if you could provide a test case to validate or validate the 5.14 snapshot. If you still see a problem, please include the logging information > Topic messages can't be sent to DLQ, because region destination value is null > - > > Key: AMQ-5454 > URL: https://issues.apache.org/jira/browse/AMQ-5454 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.10.0 > Environment: published and subscriber connections created via Spring > xml configuration file. > The messages are persistent (Durable subscription) >Reporter: Gustavo Lara >Assignee: Gary Tully > Fix For: 5.14.0 > > > When Topic.send is executed, the message is stored with the proper region > destination. > When RegionBroker.sendToDeadLetterQueue is called, for some reason the call > to MessageReference node.getRegionDestinations (ln 728) is null. > MessageReference is an instance of ActiveMQBlobMessage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6070) originalDestination property of advisory messages set to message id in error
[ https://issues.apache.org/jira/browse/AMQ-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046768#comment-15046768 ] ASF subversion and git services commented on AMQ-6070: -- Commit 88ec9dad9dc47790a3fc4e0f5ad939ea5530dad7 in activemq's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=88ec9da ] https://issues.apache.org/jira/browse/AMQ-5454 https://issues.apache.org/jira/browse/AMQ-6070 - in the case of duplicates from the store the regiondestination was not set > originalDestination property of advisory messages set to message id in error > > > Key: AMQ-6070 > URL: https://issues.apache.org/jira/browse/AMQ-6070 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 5.12.2, 5.13.1, 5.14.0 > > > The discarded/consumed/delivered advisories have the messageid as the value > of the property key originalDestination in error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5454) Topic messages can't be sent to DLQ, because region destination value is null
[ https://issues.apache.org/jira/browse/AMQ-5454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046766#comment-15046766 ] ASF subversion and git services commented on AMQ-5454: -- Commit 88ec9dad9dc47790a3fc4e0f5ad939ea5530dad7 in activemq's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=88ec9da ] https://issues.apache.org/jira/browse/AMQ-5454 https://issues.apache.org/jira/browse/AMQ-6070 - in the case of duplicates from the store the regiondestination was not set > Topic messages can't be sent to DLQ, because region destination value is null > - > > Key: AMQ-5454 > URL: https://issues.apache.org/jira/browse/AMQ-5454 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.10.0 > Environment: published and subscriber connections created via Spring > xml configuration file. > The messages are persistent (Durable subscription) >Reporter: Gustavo Lara > Fix For: NEEDS_REVIEW > > > When Topic.send is executed, the message is stored with the proper region > destination. > When RegionBroker.sendToDeadLetterQueue is called, for some reason the call > to MessageReference node.getRegionDestinations (ln 728) is null. > MessageReference is an instance of ActiveMQBlobMessage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5454) Topic messages can't be sent to DLQ, because region destination value is null
[ https://issues.apache.org/jira/browse/AMQ-5454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046762#comment-15046762 ] Gary Tully commented on AMQ-5454: - do you have a stack trace with a npe from the log or a test case? As part of https://issues.apache.org/jira/browse/AMQ-6070 I added a fix for the case of a message expiring before dispatch by setting the regionDestination earlier. A stack trace would help identify if that fix resolved this. > Topic messages can't be sent to DLQ, because region destination value is null > - > > Key: AMQ-5454 > URL: https://issues.apache.org/jira/browse/AMQ-5454 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.10.0 > Environment: published and subscriber connections created via Spring > xml configuration file. > The messages are persistent (Durable subscription) >Reporter: Gustavo Lara > Fix For: NEEDS_REVIEW > > > When Topic.send is executed, the message is stored with the proper region > destination. > When RegionBroker.sendToDeadLetterQueue is called, for some reason the call > to MessageReference node.getRegionDestinations (ln 728) is null. > MessageReference is an instance of ActiveMQBlobMessage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6070) originalDestination property of advisory messages set to message id in error
[ https://issues.apache.org/jira/browse/AMQ-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046760#comment-15046760 ] ASF subversion and git services commented on AMQ-6070: -- Commit 179dc3acb28a8a7fc3c1eddf6c6ac54fe49836a5 in activemq's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=179dc3a ] https://issues.apache.org/jira/browse/AMQ-6070 - rework for virtual topic case, use the destination from the transient region destination rather than the message, such that consumer queue advisories work for delivered etc > originalDestination property of advisory messages set to message id in error > > > Key: AMQ-6070 > URL: https://issues.apache.org/jira/browse/AMQ-6070 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 5.12.2, 5.13.1, 5.14.0 > > > The discarded/consumed/delivered advisories have the messageid as the value > of the property key originalDestination in error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6013) Restrict classes that can be serialized in ObjectMessages
[ https://issues.apache.org/jira/browse/AMQ-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046732#comment-15046732 ] Moritz Bechler commented on AMQ-6013: - Yes, that's correct. There has been some discussion about how to assign CVE's for these issues on oss-security that imho has not really come to a sensible conclusion (these both directly refer to commons-collections, I think we should have a more general one). If you don't want to go through that again, I think refering to CVE-2015-4852 would be most appropriate choice (at least Oracle has suggested that they are okay with it's reuse: http://seclists.org/oss-sec/2015/q4/306). Maybe you should check back with the Apache Security Team to see what's their opinion on this. > Restrict classes that can be serialized in ObjectMessages > - > > Key: AMQ-6013 > URL: https://issues.apache.org/jira/browse/AMQ-6013 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.11.3, 5.13.0 > > > At some points we do (de)serialization of JMS Object messages inside the > broker (HTTP, Stomp, Web Console, ...). We need to restrict classes that can > be serialized in this way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6013) Restrict classes that can be serialized in ObjectMessages
[ https://issues.apache.org/jira/browse/AMQ-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046712#comment-15046712 ] Dejan Bosanac commented on AMQ-6013: Hi Imran, yes it's the same root of the issue. I'm working on documenting and disclosing everything, so more information will be available in the coming days. > Restrict classes that can be serialized in ObjectMessages > - > > Key: AMQ-6013 > URL: https://issues.apache.org/jira/browse/AMQ-6013 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.11.3, 5.13.0 > > > At some points we do (de)serialization of JMS Object messages inside the > broker (HTTP, Stomp, Web Console, ...). We need to restrict classes that can > be serialized in this way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6013) Restrict classes that can be serialized in ObjectMessages
[
https://issues.apache.org/jira/browse/AMQ-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046701#comment-15046701
]
Imran Ali commented on AMQ-6013:
Based on [~mbechler] comment:
Can you please confirm if this fix is also based on
http://cwe.mitre.org/data/definitions/502.html
for following CVEs
CVE-2015-8103 and CVE-2015-4852
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-8103
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4852
If so you are right as a note on Vulnerability Notes Database suggest following
{quote}
Developers need to re-architect their applications, and should be suspicious of
deserialized data from untrusted sources
{quote}
> Restrict classes that can be serialized in ObjectMessages
> -
>
> Key: AMQ-6013
> URL: https://issues.apache.org/jira/browse/AMQ-6013
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.12.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
> Fix For: 5.11.3, 5.13.0
>
>
> At some points we do (de)serialization of JMS Object messages inside the
> broker (HTTP, Stomp, Web Console, ...). We need to restrict classes that can
> be serialized in this way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6013) Restrict classes that can be serialized in ObjectMessages
[ https://issues.apache.org/jira/browse/AMQ-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046700#comment-15046700 ] Dejan Bosanac commented on AMQ-6013: Hi Brett, yes we already discussed this on the dev list and decided to tackle this problem. I raised [AMQ-6077] for this work and we should address it with 5.13.1 release. > Restrict classes that can be serialized in ObjectMessages > - > > Key: AMQ-6013 > URL: https://issues.apache.org/jira/browse/AMQ-6013 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.11.3, 5.13.0 > > > At some points we do (de)serialization of JMS Object messages inside the > broker (HTTP, Stomp, Web Console, ...). We need to restrict classes that can > be serialized in this way. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6077) Better configuration of restricted classes for clients
Dejan Bosanac created AMQ-6077: -- Summary: Better configuration of restricted classes for clients Key: AMQ-6077 URL: https://issues.apache.org/jira/browse/AMQ-6077 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.13.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.13.1 [AMQ-6013] introduces the checks on the classes that are allowed to be serialized through ObjectMessages. The original implementation was designed to protect the broker, so system property configuration was the easiest solution. This change affect the clients that uses ObjectMessages.getObject() method. We need to provide a better way of configuring this for clients. My initial idea is that we should provide a configuration on ActiveMQConnectionFactory and ActiveMQComponent classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQNET-514) Lazy loading of map messages does not work correctly
[
https://issues.apache.org/jira/browse/AMQNET-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Probst updated AMQNET-514:
-
Environment:
Apache NMS 1.7.0.3635
Apache NMS ActiveMQ 1.7.0.3660
Runtime Version v4.0.30319
Spring Messaging NMS 2.0.1.4
was:
Apache NMS 1.7.0.3635
Apache NMS ActiveMQ 1.7.0.3660
Runtime Version v4.0.30319
> Lazy loading of map messages does not work correctly
>
>
> Key: AMQNET-514
> URL: https://issues.apache.org/jira/browse/AMQNET-514
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
>Affects Versions: 1.7.0, 1.7.1
> Environment: Apache NMS 1.7.0.3635
> Apache NMS ActiveMQ 1.7.0.3660
> Runtime Version v4.0.30319
> Spring Messaging NMS 2.0.1.4
>Reporter: Oliver Probst
>Assignee: Jim Gomes
>Priority: Critical
> Labels: test
>
> I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use
> two persistent queues. Dequeuing without accessing the message and then
> queuing the same message again results in a removal of the complete body of
> the map message. The use case is that we move a map message to an error queue
> if an exception occurs while dequeuing. I've got a unit test which shows that
> behaviour (unit test fails but should not) with one persistent queue
> (queue=>dequeue=>queue=>dequeue):
> [Test]
> public void QueueDequeueQueueDequeueTest()
> {
> IConnectionFactory factory = CreateConnectionFactory();
> var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout = 5000 };
> // Queue
> nmsTemplate.SendWithDelegate("queue://FOO.BAR", delegate(ISession session)
> {
> var mapMessage = session.CreateMapMessage();
> mapMessage.Body.SetString("Unit-Test-Key", "Unit-Test-Value");
> return mapMessage;
> });
> // Dequeue
> var currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as IMapMessage;
> Assert.IsNotNull(currentMessage, "currentMessage is null");
> // Queue
> IMapMessage message = currentMessage;
> nmsTemplate.SendWithDelegate("queue://FOO.BAR", session => message);
> Assert.IsNotNull(currentMessage, "currentMessage is null");
> // Dequeue
> currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as IMapMessage;
> Assert.IsNotNull(currentMessage, "currentMessage is null");
> Assert.IsTrue(currentMessage.Body.Contains("Unit-Test-Key"), "Unit-Test-Key
> does not exist");
> }
> I've checked the implementation. Using text messages everything is fine, but
> within the Apache.NMS.ActiveMQ.Commands.ActiveMQMapMessage class the Body
> property implementation is broken (with high probability ;-))
> Thanks for going on with Apache NMS!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQNET-514) Lazy loading of map messages does not work correctly
[
https://issues.apache.org/jira/browse/AMQNET-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Probst updated AMQNET-514:
-
Description:
I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use two
persistent queues. Dequeuing without accessing the message and then queuing the
same message again results in a removal of the complete body of the map
message. The use case is that we move a map message to an error queue if an
exception occurs while dequeuing. I've got a unit test which shows that
behaviour (unit test fails but should not) with one persistent queue
(queue=>dequeue=>queue=>dequeue):
[Test]
public void QueueDequeueQueueDequeueTest()
{
IConnectionFactory factory = CreateConnectionFactory();
var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout = 5000 };
// Queue
nmsTemplate.SendWithDelegate("queue://FOO.BAR", delegate(ISession session)
{
var mapMessage = session.CreateMapMessage();
mapMessage.Body.SetString("Unit-Test-Key", "Unit-Test-Value");
return mapMessage;
});
// Dequeue
var currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Queue
IMapMessage message = currentMessage;
nmsTemplate.SendWithDelegate("queue://FOO.BAR", session => message);
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Dequeue
currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
Assert.IsTrue(currentMessage.Body.Contains("Unit-Test-Key"), "Unit-Test-Key
does not exist");
}
I've checked the implementation. Using text messages everything is fine, but
within the Apache.NMS.ActiveMQ.Commands.ActiveMQMapMessage class the Body
property implementation is broken (with high probability ;-))
Thanks for going on with Apache NMS!
was:
I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use two
persistent queues. Dequeuing without accessing the message and then queuing the
same message again results in a removal of the complete body of the map
message. The use case is that we move a map message to an error queue if an
exception occurs while dequeuing. I've got a unit test which shows the
behaviour with one persistent queue (queue=>dequeue=>queue=>dequeue):
[Test]
public void QueueDequeueQueueDequeueTest()
{
IConnectionFactory factory = CreateConnectionFactory();
var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout = 5000
};
// Queue
nmsTemplate.SendWithDelegate("queue://FOO.BAR", delegate(ISession
session)
{
var mapMessage = session.CreateMapMessage();
mapMessage.Body.SetString("Unit-Test-Key", "Unit-Test-Value");
return mapMessage;
});
// Dequeue
var currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Queue
IMapMessage message = currentMessage;
nmsTemplate.SendWithDelegate("queue://FOO.BAR", session => message);
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Dequeue
currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
Assert.IsTrue(currentMessage.Body.Contains("Unit-Test-Key"),
"Unit-Test-Key does not exist");
}
> Lazy loading of map messages does not work correctly
>
>
> Key: AMQNET-514
> URL: https://issues.apache.org/jira/browse/AMQNET-514
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
>Affects Versions: 1.7.0, 1.7.1
> Environment: Apache NMS 1.7.0.3635
> Apache NMS ActiveMQ 1.7.0.3660
> Runtime Version v4.0.30319
>Reporter: Oliver Probst
>Assignee: Jim Gomes
>Priority: Critical
> Labels: test
>
> I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use
> two persistent queues. Dequeuing without accessing the message and then
> queuing the same message again results in a removal of the complete body of
> the map message. The use case is that we move a map message to an error queue
> if an exception occurs while dequeuing. I've got a unit test which shows that
> behaviour (unit test fails but should not) with one persistent queue
> (queue=>dequeue=>queue=>dequeue):
> [Test]
> public void QueueDequeueQueueDequeueTest()
> {
> IConnectionFactory factory = CreateConnectionFactory();
> var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout = 5000 };
> // Queue
> nmsTemplate.SendWithDelegate("queue://FOO.BAR",
[jira] [Updated] (AMQNET-514) Lazy loading of map messages does not work correctly
[
https://issues.apache.org/jira/browse/AMQNET-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Probst updated AMQNET-514:
-
Description:
I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use two
persistent queues. Dequeuing without accessing the message and then queuing the
same message again results in a removal of the complete body of the map
message. The use case is that we move a map message to an error queue if an
exception occurs while dequeuing. I've got a unit test which shows the
behaviour with one persistent queue (queue=>dequeue=>queue=>dequeue):
[Test]
public void QueueDequeueQueueDequeueTest()
{
IConnectionFactory factory = CreateConnectionFactory();
var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout = 5000
};
// Queue
nmsTemplate.SendWithDelegate("queue://FOO.BAR", delegate(ISession
session)
{
var mapMessage = session.CreateMapMessage();
mapMessage.Body.SetString("Unit-Test-Key", "Unit-Test-Value");
return mapMessage;
});
// Dequeue
var currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Queue
IMapMessage message = currentMessage;
nmsTemplate.SendWithDelegate("queue://FOO.BAR", session => message);
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Dequeue
currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
Assert.IsTrue(currentMessage.Body.Contains("Unit-Test-Key"),
"Unit-Test-Key does not exist");
}
was:
I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use two
persistent queues. Dequeuing without accessing the message and then queuing the
same message again results in a removal of the complete body of the map
message. The use case is that we move a map message to an error queue if an
exception occurs while dequeuing. I've got a unit test which shows the
behaviour with one persistent queue (queue=>dequeue=>queue=>dequeue):
[Test]
public void QueueDequeueQueueDequeueTest()
{
IConnectionFactory factory = CreateConnectionFactory();
var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout = 5000
};
// Queue
nmsTemplate.SendWithDelegate("queue://FOO.BAR", delegate(ISession
session)
{
var mapMessage = session.CreateMapMessage();
mapMessage.Body.SetString("Unit-Test-Key", "Unit-Test-Value");
return mapMessage;
});
// Dequeue
var currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Queue
IMapMessage message = currentMessage;
nmsTemplate.SendWithDelegate("queue://FOO.BAR", session => message);
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Dequeue
currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
Assert.IsTrue(currentMessage.Body.Contains("Unit-Test-Key"),
"Unit-Test-Key does not exist");
}
> Lazy loading of map messages does not work correctly
>
>
> Key: AMQNET-514
> URL: https://issues.apache.org/jira/browse/AMQNET-514
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, NMS
>Affects Versions: 1.7.0, 1.7.1
> Environment: Apache NMS 1.7.0.3635
> Apache NMS ActiveMQ 1.7.0.3660
> Runtime Version v4.0.30319
>Reporter: Oliver Probst
>Assignee: Jim Gomes
>Priority: Critical
> Labels: test
>
> I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use
> two persistent queues. Dequeuing without accessing the message and then
> queuing the same message again results in a removal of the complete body of
> the map message. The use case is that we move a map message to an error queue
> if an exception occurs while dequeuing. I've got a unit test which shows the
> behaviour with one persistent queue (queue=>dequeue=>queue=>dequeue):
> [Test]
> public void QueueDequeueQueueDequeueTest()
> {
> IConnectionFactory factory = CreateConnectionFactory();
> var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout =
> 5000 };
> // Queue
> nmsTemplate.SendWithDelegate("queue://FOO.BAR", delegate(ISession
> session)
> {
>
[jira] [Created] (AMQNET-514) Lazy loading of map messages does not work correctly
Oliver Probst created AMQNET-514:
Summary: Lazy loading of map messages does not work correctly
Key: AMQNET-514
URL: https://issues.apache.org/jira/browse/AMQNET-514
Project: ActiveMQ .Net
Issue Type: Bug
Components: ActiveMQ, NMS
Affects Versions: 1.7.1, 1.7.0
Environment: Apache NMS 1.7.0.3635
Apache NMS ActiveMQ 1.7.0.3660
Runtime Version v4.0.30319
Reporter: Oliver Probst
Assignee: Jim Gomes
Priority: Critical
I use Apache NMS ActiveMQ together with Spring NMS and map messages. I use two
persistent queues. Dequeuing without accessing the message and then queuing the
same message again results in a removal of the complete body of the map
message. The use case is that we move a map message to an error queue if an
exception occurs while dequeuing. I've got a unit test which shows the
behaviour with one persistent queue (queue=>dequeue=>queue=>dequeue):
[Test]
public void QueueDequeueQueueDequeueTest()
{
IConnectionFactory factory = CreateConnectionFactory();
var nmsTemplate = new NmsTemplate(factory) { ReceiveTimeout = 5000
};
// Queue
nmsTemplate.SendWithDelegate("queue://FOO.BAR", delegate(ISession
session)
{
var mapMessage = session.CreateMapMessage();
mapMessage.Body.SetString("Unit-Test-Key", "Unit-Test-Value");
return mapMessage;
});
// Dequeue
var currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Queue
IMapMessage message = currentMessage;
nmsTemplate.SendWithDelegate("queue://FOO.BAR", session => message);
Assert.IsNotNull(currentMessage, "currentMessage is null");
// Dequeue
currentMessage = nmsTemplate.Receive("queue://FOO.BAR") as
IMapMessage;
Assert.IsNotNull(currentMessage, "currentMessage is null");
Assert.IsTrue(currentMessage.Body.Contains("Unit-Test-Key"),
"Unit-Test-Key does not exist");
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-6076) At some point, two MQ server synchronization abnormal?
chenkw created AMQ-6076: --- Summary: At some point, two MQ server synchronization abnormal? Key: AMQ-6076 URL: https://issues.apache.org/jira/browse/AMQ-6076 Project: ActiveMQ Issue Type: Bug Components: activemq-camel Affects Versions: 5.12.1 Environment: Configuration： Reporter: chenkw MQ1: INFO | jvm 1| 2015/11/30 20:33:26 | INFO | Establishing network connection from vm://localhost?async=false to tcp://MQ-3:61616 INFO | jvm 1| 2015/11/30 20:33:26 | WARN | Failed to add Connection localhost->ITP_MQ3-64055-1448551657492-114804:1 due to javax.jms.InvalidClientIDException: Broker: localhost - Client: NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 INFO | jvm 1| 2015/11/30 20:33:26 | INFO | Network connection between vm://localhost#109468 and tcp://MQ-3/192.168.200.35:61616@57666 shutdown due to a local error: javax.jms.InvalidClientIDException: Broker: localhost - Client: NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 INFO | jvm 1| 2015/11/30 20:33:26 | INFO | localhost bridge to ITP_MQ3 stopped INFO | jvm 1| 2015/11/30 20:33:32 | INFO | Establishing network connection from vm://localhost?async=false to tcp://MQ-3:61616 INFO | jvm 1| 2015/11/30 20:33:32 | WARN | Failed to add Connection localhost->ITP_MQ3-64055-1448551657492-114806:1 due to javax.jms.InvalidClientIDException: Broker: localhost - Client: NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 INFO | jvm 1| 2015/11/30 20:33:32 | INFO | Network connection between vm://localhost#109470 and tcp://MQ-3/192.168.200.35:61616@57667 shutdown due to a local error: javax.jms.InvalidClientIDException: Broker: localhost - Client: NC_ITP_MQ3_inbound_localhost already connected from vm://localhost#0 INFO | jvm 1| 2015/11/30 20:33:32 | INFO | localhost bridge to ITP_MQ3 stopped MQ3: INFO | jvm 1| 2015/11/30 18:58:53 | INFO | Establishing network connection from vm://ITP_MQ3?async=false to tcp://MQ-1:61616 INFO | jvm 1| 2015/11/30 18:58:53 | WARN | Failed to add Connection ITP_MQ3->localhost-65195-1448550819638-112421:1 due to javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 INFO | jvm 1| 2015/11/30 18:58:53 | INFO | Network connection between vm://ITP_MQ3#107218 and tcp://MQ-1/192.168.200.13:61616@57199 shutdown due to a local error: javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 INFO | jvm 1| 2015/11/30 18:58:53 | INFO | ITP_MQ3 bridge to localhost stopped INFO | jvm 1| 2015/11/30 18:58:58 | INFO | Establishing network connection from vm://ITP_MQ3?async=false to tcp://MQ-1:61616 INFO | jvm 1| 2015/11/30 18:58:58 | WARN | Failed to add Connection ITP_MQ3->localhost-65195-1448550819638-112423:1 due to javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 INFO | jvm 1| 2015/11/30 18:58:58 | INFO | Network connection between vm://ITP_MQ3#107220 and tcp://MQ-1/192.168.200.13:61616@57200 shutdown due to a local error: javax.jms.InvalidClientIDException: Broker: ITP_MQ3 - Client: NC_localhost_inbound_ITP_MQ3 already connected from vm://ITP_MQ3#2 INFO | jvm 1| 2015/11/30 18:58:58 | INFO | ITP_MQ3 bridge to localhost stopped -- This message was sent by Atlassian JIRA (v6.3.4#6332)
