[jira] [Commented] (AMQ-6937) Recycling TCP/IP stack on z/OS causes an infinite error loop in transport server
[ https://issues.apache.org/jira/browse/AMQ-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16441979#comment-16441979 ] Tomas Pavelka commented on AMQ-6937: Thanks, I see it now. The number of open sockets will be capped by the code in org.apache.activemq.transport.tcp.TcpTransportServer#doHandleSocket so on Linux you are unlikely to run into the spin loop and even if you do it can be fixed by correctly setting up limits. That would make this a z/OS only problem. In our installation the problem is quite common as people recycle the TCPIP stack often to make configuration changes which causes the infinite spin loop. Unfortunately I can't think of any other way to handle this and if I don't get the fix in mainline ActiveMQ I would have to run with a forked version which is something I would very much like to avoid... > Recycling TCP/IP stack on z/OS causes an infinite error loop in transport > server > > > Key: AMQ-6937 > URL: https://issues.apache.org/jira/browse/AMQ-6937 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.3 >Reporter: Tomas Pavelka >Priority: Major > Attachments: AMQ-6937-cpu-spin-prevention.patch > > > The ActiveMQ transport servers (e.g. TcpTransportServer) run the socket > accept (java.net.ServerSocket#accept) in an infinite loop. The accept call > can repeatedly fail with an exception spinning the CPU at full speed an > filling up logs quickly. > Here is an example of an exception that gets repeated indefinitely: > java.net.SocketException: EDC5122I Input/output error. (Accept failed) > at java.net.ServerSocket.implAccept(ServerSocket.java:623) > at java.net.ServerSocket.accept(ServerSocket.java:582) > at > org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:351) > at java.lang.Thread.run(Thread.java:785) > This is a common problem on z/OS because the pattern of running accept in a > loop is used in many open source projects. For example, here is the same > issue in Derby: > https://issues.apache.org/jira/browse/DERBY-5347 > And here in Jetty: > [https://github.com/eclipse/jetty.project/issues/283] > Whenever the problem appears the socket becomes unusable. Would it be > possible for ActiveMQ to allow to insert a custom > org.apache.activemq.transport.TransportAcceptListener that would detect the > problem and do a re-bind on the socket? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6937) Recycling TCP/IP stack on z/OS causes an infinite error loop in transport server
[ https://issues.apache.org/jira/browse/AMQ-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16440868#comment-16440868 ] Tomas Pavelka commented on AMQ-6937: I have discovered that the CPU spin loop can happen even on Linux: whenever the process runs out of file descriptors the accept enters a loop that spins the CPU at 100%. I have attached a patch that slows down exception handling in such case. > Recycling TCP/IP stack on z/OS causes an infinite error loop in transport > server > > > Key: AMQ-6937 > URL: https://issues.apache.org/jira/browse/AMQ-6937 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.3 >Reporter: Tomas Pavelka >Priority: Major > Attachments: AMQ-6937-cpu-spin-prevention.patch > > > The ActiveMQ transport servers (e.g. TcpTransportServer) run the socket > accept (java.net.ServerSocket#accept) in an infinite loop. The accept call > can repeatedly fail with an exception spinning the CPU at full speed an > filling up logs quickly. > Here is an example of an exception that gets repeated indefinitely: > java.net.SocketException: EDC5122I Input/output error. (Accept failed) > at java.net.ServerSocket.implAccept(ServerSocket.java:623) > at java.net.ServerSocket.accept(ServerSocket.java:582) > at > org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:351) > at java.lang.Thread.run(Thread.java:785) > This is a common problem on z/OS because the pattern of running accept in a > loop is used in many open source projects. For example, here is the same > issue in Derby: > https://issues.apache.org/jira/browse/DERBY-5347 > And here in Jetty: > [https://github.com/eclipse/jetty.project/issues/283] > Whenever the problem appears the socket becomes unusable. Would it be > possible for ActiveMQ to allow to insert a custom > org.apache.activemq.transport.TransportAcceptListener that would detect the > problem and do a re-bind on the socket? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-6937) Recycling TCP/IP stack on z/OS causes an infinite error loop in transport server
[ https://issues.apache.org/jira/browse/AMQ-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6937: --- Attachment: AMQ-6937-cpu-spin-prevention.patch > Recycling TCP/IP stack on z/OS causes an infinite error loop in transport > server > > > Key: AMQ-6937 > URL: https://issues.apache.org/jira/browse/AMQ-6937 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.3 >Reporter: Tomas Pavelka >Priority: Major > Attachments: AMQ-6937-cpu-spin-prevention.patch > > > The ActiveMQ transport servers (e.g. TcpTransportServer) run the socket > accept (java.net.ServerSocket#accept) in an infinite loop. The accept call > can repeatedly fail with an exception spinning the CPU at full speed an > filling up logs quickly. > Here is an example of an exception that gets repeated indefinitely: > java.net.SocketException: EDC5122I Input/output error. (Accept failed) > at java.net.ServerSocket.implAccept(ServerSocket.java:623) > at java.net.ServerSocket.accept(ServerSocket.java:582) > at > org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:351) > at java.lang.Thread.run(Thread.java:785) > This is a common problem on z/OS because the pattern of running accept in a > loop is used in many open source projects. For example, here is the same > issue in Derby: > https://issues.apache.org/jira/browse/DERBY-5347 > And here in Jetty: > [https://github.com/eclipse/jetty.project/issues/283] > Whenever the problem appears the socket becomes unusable. Would it be > possible for ActiveMQ to allow to insert a custom > org.apache.activemq.transport.TransportAcceptListener that would detect the > problem and do a re-bind on the socket? > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-6937) Recycling TCP/IP stack on z/OS causes an infinite error loop in transport server
Tomas Pavelka created AMQ-6937: -- Summary: Recycling TCP/IP stack on z/OS causes an infinite error loop in transport server Key: AMQ-6937 URL: https://issues.apache.org/jira/browse/AMQ-6937 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.15.3 Reporter: Tomas Pavelka The ActiveMQ transport servers (e.g. TcpTransportServer) run the socket accept (java.net.ServerSocket#accept) in an infinite loop. The accept call can repeatedly fail with an exception spinning the CPU at full speed an filling up logs quickly. Here is an example of an exception that gets repeated indefinitely: java.net.SocketException: EDC5122I Input/output error. (Accept failed) at java.net.ServerSocket.implAccept(ServerSocket.java:623) at java.net.ServerSocket.accept(ServerSocket.java:582) at org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:351) at java.lang.Thread.run(Thread.java:785) This is a common problem on z/OS because the pattern of running accept in a loop is used in many open source projects. For example, here is the same issue in Derby: https://issues.apache.org/jira/browse/DERBY-5347 And here in Jetty: [https://github.com/eclipse/jetty.project/issues/283] Whenever the problem appears the socket becomes unusable. Would it be possible for ActiveMQ to allow to insert a custom org.apache.activemq.transport.TransportAcceptListener that would detect the problem and do a re-bind on the socket? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6863: --- Attachment: TestActiveSubscriptions.java TestHighMemoryWaterMark.java I have attached two tests: *TestActiveSubscriptions* shows that if we set org.apache.activemq.broker.BrokerService#setKeepDurableSubsActive to false, then messages do not flow on durable topics. The test passes if the setting is back at the default "true". *TestHighMemoryWatermark* shows how we would expect the highWatermark settings to work, i.e. when one topic hits its own watermark we can still send messages on another topic. Let me know if there is something we are not setting correctly. Thanks, Tomas > NPE when expiring messages with FilePendingMessageCursor and durable topic > subscriptions > > > Key: AMQ-6863 > URL: https://issues.apache.org/jira/browse/AMQ-6863 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.2 >Reporter: Tomas Pavelka > Attachments: TestActiveSubscriptions.java, TestCursors.java, > TestHighMemoryWaterMark.java > > > I am using a file based cursor with durable topic subscriptions because in my > tests the broker would run out of memory when dealing with large numbers of > messages without an active consumer. > I have run into a NullPointerException when the messages meant for the topic > with an active durable subscription expire. Here is part of the stack trace: > java.lang.NullPointerException: null > at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) > [activemq-broker-5.15.2.jar:5.15.2] > at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at >
[jira] [Comment Edited] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264227#comment-16264227 ] Tomas Pavelka edited comment on AMQ-6863 at 11/23/17 11:48 AM: --- Here is why we can only achieve what we want with a file cursor, despite the file cursor saving to disk twice: We have a group of topics (let's call them LIMITED.TOPIC) with durable subscribers that we want to limit by policies. For example, we set a policy that these topics can only use 70% of storage so that other destinations can still use the broker even if LIMITED.TOPIC fills up storage up to the limit allowed by policy. We can run into a situation, where a durable consumer disconnect. We are using a hub and spoke topology, so eventually when the consumer is disconnected for long enough the storage for both hub and the sending broker fills up, here is a picture: spoke_broker(LIMITED.TOPIC:full) -> hub_broker(LIMITED.TOPIC:full) In this situation, hub_broker has an inactive durable subscription from the disconnected consumer, but spoke_broker has an active subscription from hub_broker. Now spoke_broker will put messages from LIMITED.TOPIC into memory *up to the global limit* (as opposed to policy set high watermark). This results in a situation where spoke_broker cannot process any other messages because its memory is full. The only way we were able to solve this is by using a file cursor which (I guess) respects policy watermarks. But the file cursor has the bug with message expiration. was (Author: tpavelka): Here is why we can only achieve what we want with a file cursor, despite the file cursor saving to disk twice: We have a group of topics (let's call them LIMITED.TOPIC) with durable subscribers that we want to limit by policies. For example, we set a policy that these topics can only use 70% of storage so that other destinations can still use the broker even if LIMITED.TOPIC fills up storage up to the limit allowed by policy. We can run into a situation, where a durable consumer disconnect. We are using a hub and spoke topology, so eventually when the consumer is disconnected for long enough the storage for both hub and the sending broker fills up, here is a picture: spoke_broker(LIMITED.TOPIC:full) -> hub_broker(LIMITED.TOPIC:full) In this situation, hub_broker has an inactive durable subscription from the disconnected consumer, but spoke_broker has an active subscription from hub_broker. In this situation, spoke_broker will put messages from LIMITED.TOPIC into memory *up to the global limit* (as opposed to policy set high watermark). This results in a situation where spoke_broker cannot process any other messages because its memory is full. The only way we were able to solve this is by using a file cursor which (I guess) respects policy watermarks. But the file cursor has the bug with message expiration. > NPE when expiring messages with FilePendingMessageCursor and durable topic > subscriptions > > > Key: AMQ-6863 > URL: https://issues.apache.org/jira/browse/AMQ-6863 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.2 >Reporter: Tomas Pavelka > Attachments: TestCursors.java > > > I am using a file based cursor with durable topic subscriptions because in my > tests the broker would run out of memory when dealing with large numbers of > messages without an active consumer. > I have run into a NullPointerException when the messages meant for the topic > with an active durable subscription expire. Here is part of the stack trace: > java.lang.NullPointerException: null > at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) > [activemq-broker-5.15.2.jar:5.15.2] > at >
[jira] [Commented] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16264227#comment-16264227 ] Tomas Pavelka commented on AMQ-6863: Here is why we can only achieve what we want with a file cursor, despite the file cursor saving to disk twice: We have a group of topics (let's call them LIMITED.TOPIC) with durable subscribers that we want to limit by policies. For example, we set a policy that these topics can only use 70% of storage so that other destinations can still use the broker even if LIMITED.TOPIC fills up storage up to the limit allowed by policy. We can run into a situation, where a durable consumer disconnect. We are using a hub and spoke topology, so eventually when the consumer is disconnected for long enough the storage for both hub and the sending broker fills up, here is a picture: spoke_broker(LIMITED.TOPIC:full) -> hub_broker(LIMITED.TOPIC:full) In this situation, hub_broker has an inactive durable subscription from the disconnected consumer, but spoke_broker has an active subscription from hub_broker. In this situation, spoke_broker will put messages from LIMITED.TOPIC into memory *up to the global limit* (as opposed to policy set high watermark). This results in a situation where spoke_broker cannot process any other messages because its memory is full. The only way we were able to solve this is by using a file cursor which (I guess) respects policy watermarks. But the file cursor has the bug with message expiration. > NPE when expiring messages with FilePendingMessageCursor and durable topic > subscriptions > > > Key: AMQ-6863 > URL: https://issues.apache.org/jira/browse/AMQ-6863 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.2 >Reporter: Tomas Pavelka > Attachments: TestCursors.java > > > I am using a file based cursor with durable topic subscriptions because in my > tests the broker would run out of memory when dealing with large numbers of > messages without an active consumer. > I have run into a NullPointerException when the messages meant for the topic > with an active durable subscription expire. Here is part of the stack trace: > java.lang.NullPointerException: null > at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) > [activemq-broker-5.15.2.jar:5.15.2] > at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) > [activemq-broker-5.15.2.jar:5.15.2] > at >
[jira] [Updated] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6863: --- Description: I am using a file based cursor with durable topic subscriptions because in my tests the broker would run out of memory when dealing with large numbers of messages without an active consumer. I have run into a NullPointerException when the messages meant for the topic with an active durable subscription expire. Here is part of the stack trace: java.lang.NullPointerException: null at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.TransactionBroker.start(TransactionBroker.java:119) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService$6.start(BrokerService.java:2370) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:747) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:733) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.start(BrokerService.java:636) [activemq-broker-5.15.2.jar:5.15.2] I looked at the code and it seems to me that this is caused by the method
[jira] [Updated] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6863: --- Description: I am using a file based cursor with durable topic subscriptions because in my tests the broker would run out of memory when dealing with large numbers of messages without an active consumer. I have run into a NullPointerException when the messages meant for the topic with an active durable subscription expire. Here is part of the stack trace: java.lang.NullPointerException: null at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.TransactionBroker.start(TransactionBroker.java:119) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService$6.start(BrokerService.java:2370) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:747) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:733) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.start(BrokerService.java:636) [activemq-broker-5.15.2.jar:5.15.2] I looked at the code and it seems to me that this is caused by the method
[jira] [Comment Edited] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253669#comment-16253669 ] Tomas Pavelka edited comment on AMQ-6863 at 11/15/17 3:52 PM: -- The attached test (TestCursors.java) reproduces the problem. was (Author: tpavelka): The attached test reproduces the problem. > NPE when expiring messages with FilePendingMessageCursor and durable topic > subscriptions > > > Key: AMQ-6863 > URL: https://issues.apache.org/jira/browse/AMQ-6863 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.2 >Reporter: Tomas Pavelka > Attachments: TestCursors.java > > > I am using a file based cursor with durable topic subscriptions because in my > tests the broker would run out of memory when dealing with large numbers of > messages without an active consumer. > I have run into a NullPointerException when the messages meant for the topic > with an active durable subscription expire. Here is part of the stack trace: > java.lang.NullPointerException: null > at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) > [activemq-broker-5.15.2.jar:5.15.2] > at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) > [activemq-broker-5.15.2.jar:5.15.2] >
[jira] [Comment Edited] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16253669#comment-16253669 ] Tomas Pavelka edited comment on AMQ-6863 at 11/15/17 3:51 PM: -- The attached test reproduces the problem. was (Author: tpavelka): This reproduces the problem. > NPE when expiring messages with FilePendingMessageCursor and durable topic > subscriptions > > > Key: AMQ-6863 > URL: https://issues.apache.org/jira/browse/AMQ-6863 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.2 >Reporter: Tomas Pavelka > Attachments: TestCursors.java > > > I am using a file based cursor with durable topic subscriptions because in my > tests the broker would run out of memory when dealing with large numbers of > messages without an active consumer. > I have run into a NullPointerException when the messages meant for the topic > with an active durable subscription expire. Here is part of the stack trace: > java.lang.NullPointerException: null > at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) > [activemq-broker-5.15.2.jar:5.15.2] > at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) > [activemq-broker-5.15.2.jar:5.15.2] > at >
[jira] [Updated] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6863: --- Attachment: TestCursors.java This reproduces the problem. > NPE when expiring messages with FilePendingMessageCursor and durable topic > subscriptions > > > Key: AMQ-6863 > URL: https://issues.apache.org/jira/browse/AMQ-6863 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.2 >Reporter: Tomas Pavelka > Attachments: TestCursors.java > > > I am using a file based cursor with durable topic subscriptions because in my > tests the broker would run out of memory when dealing with large numbers of > messages without an active consumer. > I have run into a NullPointerException when the messages meant for the topic > with an active durable subscription expire. Here is part of the stack trace: > java.lang.NullPointerException: null > at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) > [activemq-kahadb-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) > [activemq-broker-5.15.2.jar:5.15.2] > at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) > [activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) > [activemq-broker-5.15.2.jar:5.15.2] > at >
[jira] [Updated] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[
https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Pavelka updated AMQ-6863:
---
Description:
I am using a file based cursor with durable topic subscriptions because in my
tests the broker would run out of memory when dealing with large numbers of
messages without an active consumer.
I have run into a NullPointerException when the messages meant for the topic
with an active durable subscription expire. Here is part of the stack trace:
{{java.lang.NullPointerException: null
at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012)
[activemq-kahadb-store-5.15.2.jar:5.15.2]
at
org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779)
[activemq-kahadb-store-5.15.2.jar:5.15.2]
at
org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999)
[activemq-kahadb-store-5.15.2.jar:5.15.2]
at
org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108)
[activemq-broker-5.15.2.jar:5.15.2]
at org.apache.activemq.broker.region.Topic.activate(Topic.java:307)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200)
[activemq-broker-5.15.2.jar:5.15.2]
at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189)
[activemq-broker-5.15.2.jar:5.15.2]
at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.TransactionBroker.start(TransactionBroker.java:119)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerService$6.start(BrokerService.java:2370)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:747)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:733)
[activemq-broker-5.15.2.jar:5.15.2]
at
org.apache.activemq.broker.BrokerService.start(BrokerService.java:636)
[activemq-broker-5.15.2.jar:5.15.2]}}
I looked at the code and it seems to me that this is caused by the method
[jira] [Updated] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
[ https://issues.apache.org/jira/browse/AMQ-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6863: --- Description: I am using a file based cursor with durable topic subscriptions because in my tests the broker would run out of memory when dealing with large numbers of messages without an active consumer. I have run into a NullPointerException when the messages meant for the topic with an active durable subscription expire. Here is part of the stack trace: java.lang.NullPointerException: null at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.TransactionBroker.start(TransactionBroker.java:119) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService$6.start(BrokerService.java:2370) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:747) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:733) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.start(BrokerService.java:636) [activemq-broker-5.15.2.jar:5.15.2] I looked at the code and it seems to me that this is caused by the method
[jira] [Created] (AMQ-6863) NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions
Tomas Pavelka created AMQ-6863: -- Summary: NPE when expiring messages with FilePendingMessageCursor and durable topic subscriptions Key: AMQ-6863 URL: https://issues.apache.org/jira/browse/AMQ-6863 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.15.2 Reporter: Tomas Pavelka I am using a file based cursor with durable topic subscriptions because in my tests the broker would run out of memory when dealing with large numbers of messages without an active consumer. I have run into a NullPointerException when the messages meant for the topic with an active durable subscription expire. Here is part of the stack trace: java.lang.NullPointerException: null at org.apache.activemq.broker.region.Topic.acknowledge(Topic.java:586) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.messageExpired(Topic.java:810) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.discardExpiredMessage(FilePendingMessageCursor.java:489) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:247) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.cursors.AbstractPendingMessageCursor.addMessageLast(AbstractPendingMessageCursor.java:93) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.PrefetchSubscription.add(PrefetchSubscription.java:157) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:279) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic$2.recoverMessage(Topic.java:314) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore$6.execute(KahaDBStore.java:1012) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.disk.page.Transaction.execute(Transaction.java:779) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.kahadb.KahaDBStore$KahaDBTopicMessageStore.recoverSubscription(KahaDBStore.java:999) [activemq-kahadb-store-5.15.2.jar:5.15.2] at org.apache.activemq.store.ProxyTopicMessageStore.recoverSubscription(ProxyTopicMessageStore.java:108) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.activate(Topic.java:307) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.DurableTopicSubscription.add(DurableTopicSubscription.java:123) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.Topic.addSubscription(Topic.java:164) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.TopicRegion.addSubscriptionsForDestination(TopicRegion.java:287) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.addDestination(AbstractRegion.java:162) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.addDestination(RegionBroker.java:339) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.advisory.AdvisoryBroker.addDestination(AdvisoryBroker.java:239) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.addDestination(BrokerFilter.java:174) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.AbstractRegion.start(AbstractRegion.java:104) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.region.RegionBroker.start(RegionBroker.java:200) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerFilter.start(BrokerFilter.java:189) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.TransactionBroker.start(TransactionBroker.java:119) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService$6.start(BrokerService.java:2370) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.doStartBroker(BrokerService.java:747) [activemq-broker-5.15.2.jar:5.15.2] at org.apache.activemq.broker.BrokerService.startBroker(BrokerService.java:733) [activemq-broker-5.15.2.jar:5.15.2] at
[jira] [Updated] (AMQ-6784) Duplicate messages received in hub and spoke topology
[
https://issues.apache.org/jira/browse/AMQ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Pavelka updated AMQ-6784:
---
Description:
If there are multiple consumers of a single topic in a hub and spoke topology
where each of the spokes has an embedded broker, then each of the consumers
receives one message sent to the topic multiple times.
The topology looks like this:
Spoke (broker) -> Hub (broker) <- Spoke (broker)
^
Spoke (broker)
If one spoke sends a message to a topic and at least two other spokes have
consumers then they will receive the message multiple times.
The likely cause is that
org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers
checks if the incoming ConsumerInfo represents a network subscription
in the topology used it does because the subscription info is passed through
two brokers
There exists a workaround: if any policy is applied to the destination then
duplication does not happen. This is because PolicyEntry#enableAudit is true by
default and is applied to
org.apache.activemq.broker.region.BaseDestination#enableAudit which is false by
default.
See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and
also demonstrates the workaround.
was:
If there are multiple consumers of a single topic in a hub and spoke topology
where each of the spokes has an embedded broker, then each of the consumers
receives one message sent to the topic multiple times.
The topology looks like this:
{{
Spoke (broker) -> Hub (broker) <- Spoke (broker)
^
Spoke (broker)
}}
If one spoke sends a message to a topic and at least two other spokes have
consumers then they will receive the message multiple times.
The likely cause is that
org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers
checks if the incoming ConsumerInfo represents a network subscription
in the topology used it does because the subscription info is passed through
two brokers
There exists a workaround: if any policy is applied to the destination then
duplication does not happen. This is because PolicyEntry#enableAudit is true by
default and is applied to
org.apache.activemq.broker.region.BaseDestination#enableAudit which is false by
default.
See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and
also demonstrates the workaround.
> Duplicate messages received in hub and spoke topology
> -
>
> Key: AMQ-6784
> URL: https://issues.apache.org/jira/browse/AMQ-6784
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Tomas Pavelka
>Priority: Minor
> Attachments: HubAndSpokeDuplicateMessages.java
>
>
> If there are multiple consumers of a single topic in a hub and spoke topology
> where each of the spokes has an embedded broker, then each of the consumers
> receives one message sent to the topic multiple times.
> The topology looks like this:
> Spoke (broker) -> Hub (broker) <- Spoke (broker)
> ^
> Spoke (broker)
> If one spoke sends a message to a topic and at least two other spokes have
> consumers then they will receive the message multiple times.
> The likely cause is that
> org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers
> checks if the incoming ConsumerInfo represents a network subscription
> in the topology used it does because the subscription info is passed through
> two brokers
> There exists a workaround: if any policy is applied to the destination then
> duplication does not happen. This is because PolicyEntry#enableAudit is true
> by default and is applied to
> org.apache.activemq.broker.region.BaseDestination#enableAudit which is false
> by default.
> See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and
> also demonstrates the workaround.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (AMQ-6784) Duplicate messages received in hub and spoke topology
[
https://issues.apache.org/jira/browse/AMQ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomas Pavelka updated AMQ-6784:
---
Description:
If there are multiple consumers of a single topic in a hub and spoke topology
where each of the spokes has an embedded broker, then each of the consumers
receives one message sent to the topic multiple times.
The topology looks like this:
{{
Spoke (broker) -> Hub (broker) <- Spoke (broker)
^
Spoke (broker)
}}
If one spoke sends a message to a topic and at least two other spokes have
consumers then they will receive the message multiple times.
The likely cause is that
org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers
checks if the incoming ConsumerInfo represents a network subscription
in the topology used it does because the subscription info is passed through
two brokers
There exists a workaround: if any policy is applied to the destination then
duplication does not happen. This is because PolicyEntry#enableAudit is true by
default and is applied to
org.apache.activemq.broker.region.BaseDestination#enableAudit which is false by
default.
See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and
also demonstrates the workaround.
was:
If there are multiple consumers of a single topic in a hub and spoke topology
where each of the spokes has an embedded broker, then each of the consumers
receives one message sent to the topic multiple times.
The topology looks like this:
Spoke (broker) -> Hub (broker) <- Spoke (broker)
^
Spoke (broker)
If one spoke sends a message to a topic and at least two other spokes have
consumers then they will receive the message multiple times.
The likely cause is that
org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers
checks if the incoming ConsumerInfo represents a network subscription
in the topology used it does because the subscription info is passed through
two brokers
There exists a workaround: if any policy is applied to the destination then
duplication does not happen. This is because PolicyEntry#enableAudit is true by
default and is applied to
org.apache.activemq.broker.region.BaseDestination#enableAudit which is false by
default.
See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and
also demonstrates the workaround.
> Duplicate messages received in hub and spoke topology
> -
>
> Key: AMQ-6784
> URL: https://issues.apache.org/jira/browse/AMQ-6784
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Tomas Pavelka
>Priority: Minor
> Attachments: HubAndSpokeDuplicateMessages.java
>
>
> If there are multiple consumers of a single topic in a hub and spoke topology
> where each of the spokes has an embedded broker, then each of the consumers
> receives one message sent to the topic multiple times.
> The topology looks like this:
> {{
> Spoke (broker) -> Hub (broker) <- Spoke (broker)
> ^
> Spoke (broker)
> }}
> If one spoke sends a message to a topic and at least two other spokes have
> consumers then they will receive the message multiple times.
> The likely cause is that
> org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers
> checks if the incoming ConsumerInfo represents a network subscription
> in the topology used it does because the subscription info is passed through
> two brokers
> There exists a workaround: if any policy is applied to the destination then
> duplication does not happen. This is because PolicyEntry#enableAudit is true
> by default and is applied to
> org.apache.activemq.broker.region.BaseDestination#enableAudit which is false
> by default.
> See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and
> also demonstrates the workaround.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (AMQ-6784) Duplicate messages received in hub and spoke topology
[ https://issues.apache.org/jira/browse/AMQ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112621#comment-16112621 ] Tomas Pavelka commented on AMQ-6784: Additional discussion of the problem is in the user forum: http://activemq.2283324.n4.nabble.com/Duplicate-messages-received-with-ActiveMQ-5-13-2-td4728627.html > Duplicate messages received in hub and spoke topology > - > > Key: AMQ-6784 > URL: https://issues.apache.org/jira/browse/AMQ-6784 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.2 >Reporter: Tomas Pavelka >Priority: Minor > Attachments: HubAndSpokeDuplicateMessages.java > > > If there are multiple consumers of a single topic in a hub and spoke topology > where each of the spokes has an embedded broker, then each of the consumers > receives one message sent to the topic multiple times. > The topology looks like this: > Spoke (broker) -> Hub (broker) <- Spoke (broker) > ^ > Spoke (broker) > If one spoke sends a message to a topic and at least two other spokes have > consumers then they will receive the message multiple times. > The likely cause is that > org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers > checks if the incoming ConsumerInfo represents a network subscription > in the topology used it does because the subscription info is passed through > two brokers > There exists a workaround: if any policy is applied to the destination then > duplication does not happen. This is because PolicyEntry#enableAudit is true > by default and is applied to > org.apache.activemq.broker.region.BaseDestination#enableAudit which is false > by default. > See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and > also demonstrates the workaround. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMQ-6784) Duplicate messages received in hub and spoke topology
[ https://issues.apache.org/jira/browse/AMQ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6784: --- Description: If there are multiple consumers of a single topic in a hub and spoke topology where each of the spokes has an embedded broker, then each of the consumers receives one message sent to the topic multiple times. The topology looks like this: Spoke (broker) -> Hub (broker) <- Spoke (broker) ^ Spoke (broker) If one spoke sends a message to a topic and at least two other spokes have consumers then they will receive the message multiple times. The likely cause is that org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers checks if the incoming ConsumerInfo represents a network subscription in the topology used it does because the subscription info is passed through two brokers There exists a workaround: if any policy is applied to the destination then duplication does not happen. This is because PolicyEntry#enableAudit is true by default and is applied to org.apache.activemq.broker.region.BaseDestination#enableAudit which is false by default. See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and also demonstrates the workaround. was: If there are multiple consumers of a single topic in a hub and spoke topology where each of the spokes has an embedded broker, then each of the consumers receives one message sent to the topic multiple times. The topology looks like this: Spoke (broker) -> Hub (broker) <- Spoke (broker) ^ Spoke (broker) If one spoke sends a message to a topic and at least two other spokes have consumers then they will receive the message multiple times. The likely cause is that org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers checks if the incoming ConsumerInfo represents a network subscription in the topology used it does because the subscription info is passed through two brokers There exists a workaround: if any policy is applied to the destination then duplication does not happen. This is because PolicyEntry#enableAudit is true by default and is applied to org.apache.activemq.broker.region.BaseDestination#enableAudit which is false by default. > Duplicate messages received in hub and spoke topology > - > > Key: AMQ-6784 > URL: https://issues.apache.org/jira/browse/AMQ-6784 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.2 >Reporter: Tomas Pavelka >Priority: Minor > Attachments: HubAndSpokeDuplicateMessages.java > > > If there are multiple consumers of a single topic in a hub and spoke topology > where each of the spokes has an embedded broker, then each of the consumers > receives one message sent to the topic multiple times. > The topology looks like this: > Spoke (broker) -> Hub (broker) <- Spoke (broker) > ^ > Spoke (broker) > If one spoke sends a message to a topic and at least two other spokes have > consumers then they will receive the message multiple times. > The likely cause is that > org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers > checks if the incoming ConsumerInfo represents a network subscription > in the topology used it does because the subscription info is passed through > two brokers > There exists a workaround: if any policy is applied to the destination then > duplication does not happen. This is because PolicyEntry#enableAudit is true > by default and is applied to > org.apache.activemq.broker.region.BaseDestination#enableAudit which is false > by default. > See the attached unit test which reproduces the issue in ActiveMQ 5.13.2 and > also demonstrates the workaround. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (AMQ-6784) Duplicate messages received in hub and spoke topology
[ https://issues.apache.org/jira/browse/AMQ-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Pavelka updated AMQ-6784: --- Attachment: HubAndSpokeDuplicateMessages.java The unit test reproduces the problem in ActiveMQ 5.13.2 and also demonstrates the workaround. > Duplicate messages received in hub and spoke topology > - > > Key: AMQ-6784 > URL: https://issues.apache.org/jira/browse/AMQ-6784 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.2 >Reporter: Tomas Pavelka >Priority: Minor > Attachments: HubAndSpokeDuplicateMessages.java > > > If there are multiple consumers of a single topic in a hub and spoke topology > where each of the spokes has an embedded broker, then each of the consumers > receives one message sent to the topic multiple times. > The topology looks like this: > Spoke (broker) -> Hub (broker) <- Spoke (broker) > ^ > Spoke (broker) > If one spoke sends a message to a topic and at least two other spokes have > consumers then they will receive the message multiple times. > The likely cause is that > org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers > checks if the incoming ConsumerInfo represents a network subscription > in the topology used it does because the subscription info is passed through > two brokers > There exists a workaround: if any policy is applied to the destination then > duplication does not happen. This is because PolicyEntry#enableAudit is true > by default and is applied to > org.apache.activemq.broker.region.BaseDestination#enableAudit which is false > by default. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (AMQ-6784) Duplicate messages received in hub and spoke topology
Tomas Pavelka created AMQ-6784: -- Summary: Duplicate messages received in hub and spoke topology Key: AMQ-6784 URL: https://issues.apache.org/jira/browse/AMQ-6784 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.13.2 Reporter: Tomas Pavelka Priority: Minor If there are multiple consumers of a single topic in a hub and spoke topology where each of the spokes has an embedded broker, then each of the consumers receives one message sent to the topic multiple times. The topology looks like this: Spoke (broker) -> Hub (broker) <- Spoke (broker) ^ Spoke (broker) If one spoke sends a message to a topic and at least two other spokes have consumers then they will receive the message multiple times. The likely cause is that org.apache.activemq.network.ConduitBridge#addToAlreadyInterestedConsumers checks if the incoming ConsumerInfo represents a network subscription in the topology used it does because the subscription info is passed through two brokers There exists a workaround: if any policy is applied to the destination then duplication does not happen. This is because PolicyEntry#enableAudit is true by default and is applied to org.apache.activemq.broker.region.BaseDestination#enableAudit which is false by default. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
