[jira] [Commented] (AMQ-6391) Memory leak with FailoverTransport when sending TX messages from MDB
[
https://issues.apache.org/jira/browse/AMQ-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413778#comment-15413778
]
Patrik Dudits commented on AMQ-6391:
I use it for failover during upgrades, but it's not a master - slave setup, the
brokers are just networked, so I assume that transaction tracking would really
not help here anyway.
But I think that this can be solved by ConnectionStateTracker having static
multi map from transactions to connections. Since all of these connections are
managed by same resource adapter, they are in same class loader.
> Memory leak with FailoverTransport when sending TX messages from MDB
>
>
> Key: AMQ-6391
> URL: https://issues.apache.org/jira/browse/AMQ-6391
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Patrik Dudits
> Attachments: 0001-AMQ-6391-test.patch
>
>
> We observe memory leak in
> {{FailoverTransport.stateTracker.connectionStates.transactions}} when using
> XA Transactions in activemq-rar, sending message within same transaction and
> not using {{useInboundSession}}.
> In such constellation there are two connections enlisted within same
> transaction. During commit the transaction manager will execute commit on one
> of the resources, per JTA 1.2 section 3.3.1 ("(TransactionManager) ensures
> that the same resource manager only receives one set of prepare-commit calls
> for completing the target global transaction ".)
> [TransactionContext|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L478]
> will propagate the afterCommit to all contexts participating in same
> transaction. However, this is not enough for {{ConnectionStateTracker}},
> which only reacts to [TransactionInfo
> command|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L469].
> In effect, when two connection are enlisted in same transaction, just
> commands of one of them is cleared upon commit, leading to memory leak.
> Since I presume the {{TransactionInfo}} should be sent only once for commit
> of single transaction, {{ConnectionStateTracker}} needs to clear state for
> the acknowledged transactions regardless of connection id in the transaction
> command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-6391) Memory leak with FailoverTransport when sending TX messages from MDB
[
https://issues.apache.org/jira/browse/AMQ-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413721#comment-15413721
]
Patrik Dudits edited comment on AMQ-6391 at 8/9/16 3:26 PM:
Apparently sending multiple commit {{TransactionInfo}} commands is not an
option. This is what the other transaction context will get:
{code}
activemq.TransactionContext: ignoring exception from after completion on ended
transaction: javax.jms.JMSException: Transaction
'XID:[86,globalId=003ffd6,branchId=003ffd6]' has not been
started. xaErrorCode:-4
javax.jms.JMSException: Transaction
'XID:[86,globalId=003ffd6,branchId=003ffd6]' has not been
started. xaErrorCode:-4
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
at
org.apache.activemq.TransactionContext.sendXaCommitInfo(TransactionContext.java:630)
at
org.apache.activemq.TransactionContext.commit(TransactionContext.java:595)
at org.apache.activemq.bugs.AMQ6391Test.commit(AMQ6391Test.java:195)
at org.apache.activemq.bugs.AMQ6391Test.access$200(AMQ6391Test.java:64)
at
org.apache.activemq.bugs.AMQ6391Test$1.onMessage(AMQ6391Test.java:116)
at
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1401)
at
org.apache.activemq.ActiveMQSessionExecutor.dispatch(ActiveMQSessionExecutor.java:131)
at
org.apache.activemq.ActiveMQSessionExecutor.iterate(ActiveMQSessionExecutor.java:202)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: javax.transaction.xa.XAException: Transaction
'XID:[86,globalId=003ffd6,branchId=003ffd6]' has not been
started. xaErrorCode:-4
at
org.apache.activemq.transaction.Transaction.newXAException(Transaction.java:212)
at
org.apache.activemq.broker.TransactionBroker.getTransaction(TransactionBroker.java:351)
at
org.apache.activemq.broker.TransactionBroker.commitTransaction(TransactionBroker.java:251)
at
org.apache.activemq.broker.MutableBrokerFilter.commitTransaction(MutableBrokerFilter.java:118)
at
org.apache.activemq.broker.TransportConnection.processCommitTransactionOnePhase(TransportConnection.java:535)
at
org.apache.activemq.command.TransactionInfo.visit(TransactionInfo.java:100)
at
org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:333)
at
org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:197)
at
org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
at
org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
at
org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:273)
... 5 more
{code}
The code can be seen at
https://github.com/pdudits/activemq/commit/98985af1d4e5800e550562d68a2879697a5051ea
was (Author: pdudits):
Apparently sending multiple commit {{TransactionInfo}}s is not an option. This
is what the other transaction context will get:
{code}
activemq.TransactionContext: ignoring exception from after completion on ended
transaction: javax.jms.JMSException: Transaction
'XID:[86,globalId=003ffd6,branchId=003ffd6]' has not been
started. xaErrorCode:-4
javax.jms.JMSException: Transaction
'XID:[86,globalId=003ffd6,branchId=003ffd6]' has not been
started. xaErrorCode:-4
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
at
org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
at
org.apache.activemq.TransactionContext.sendXaCommitInfo(TransactionContext.java:630)
at
org.apache.activemq.TransactionContext.commit(TransactionContext.java:595)
at org.apache.activemq.bugs.AMQ6391Test.commit(AMQ6391Test.java:195)
at org.apache.activemq.bugs.AMQ6391Test.access$200(AMQ6391Test.java:64)
at
org.apache.activemq.bugs.AMQ6391Test$1.onMessage(AMQ6391Test.java:116)
at
org.apache.activemq.ActiveMQMessageConsumer.dispatch(ActiveMQMessageConsumer.java:1401)
at
[jira] [Updated] (AMQ-6391) Memory leak with FailoverTransport when sending TX messages from MDB
[
https://issues.apache.org/jira/browse/AMQ-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrik Dudits updated AMQ-6391:
---
Attachment: 0001-AMQ-6391-test.patch
This test reproduces the issue. I'll try modifying TransactionContext and
submitting a PR.
> Memory leak with FailoverTransport when sending TX messages from MDB
>
>
> Key: AMQ-6391
> URL: https://issues.apache.org/jira/browse/AMQ-6391
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Patrik Dudits
> Attachments: 0001-AMQ-6391-test.patch
>
>
> We observe memory leak in
> {{FailoverTransport.stateTracker.connectionStates.transactions}} when using
> XA Transactions in activemq-rar, sending message within same transaction and
> not using {{useInboundSession}}.
> In such constellation there are two connections enlisted within same
> transaction. During commit the transaction manager will execute commit on one
> of the resources, per JTA 1.2 section 3.3.1 ("(TransactionManager) ensures
> that the same resource manager only receives one set of prepare-commit calls
> for completing the target global transaction ".)
> [TransactionContext|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L478]
> will propagate the afterCommit to all contexts participating in same
> transaction. However, this is not enough for {{ConnectionStateTracker}},
> which only reacts to [TransactionInfo
> command|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L469].
> In effect, when two connection are enlisted in same transaction, just
> commands of one of them is cleared upon commit, leading to memory leak.
> Since I presume the {{TransactionInfo}} should be sent only once for commit
> of single transaction, {{ConnectionStateTracker}} needs to clear state for
> the acknowledged transactions regardless of connection id in the transaction
> command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6391) Memory leak with FailoverTransport when sending TX messages from MDB
[
https://issues.apache.org/jira/browse/AMQ-6391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15413541#comment-15413541
]
Patrik Dudits commented on AMQ-6391:
Thanks Gary,
yes, moving to {{useInboundSession}} is indeed what we are going to do in the
meantime.
The connections are getting xa-end, just the commit is reaching only the
topmost one. If it is OK for broker to receive commit command for single
transaction from multiple connections, then the solution appears to be easy -
[afterCommit|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L596]
is fired for all participating transaction contexts already, they just need to
send the transaction info if they already didn't.
I'll see if I can build a testcase for this, and can try this approach.
And for reference, I originally asked this on user mailing list:
http://activemq.2283324.n4.nabble.com/Messages-piling-up-in-FailoverTranport-td4715072.html
> Memory leak with FailoverTransport when sending TX messages from MDB
>
>
> Key: AMQ-6391
> URL: https://issues.apache.org/jira/browse/AMQ-6391
> Project: ActiveMQ
> Issue Type: Bug
>Reporter: Patrik Dudits
>
> We observe memory leak in
> {{FailoverTransport.stateTracker.connectionStates.transactions}} when using
> XA Transactions in activemq-rar, sending message within same transaction and
> not using {{useInboundSession}}.
> In such constellation there are two connections enlisted within same
> transaction. During commit the transaction manager will execute commit on one
> of the resources, per JTA 1.2 section 3.3.1 ("(TransactionManager) ensures
> that the same resource manager only receives one set of prepare-commit calls
> for completing the target global transaction ".)
> [TransactionContext|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L478]
> will propagate the afterCommit to all contexts participating in same
> transaction. However, this is not enough for {{ConnectionStateTracker}},
> which only reacts to [TransactionInfo
> command|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L469].
> In effect, when two connection are enlisted in same transaction, just
> commands of one of them is cleared upon commit, leading to memory leak.
> Since I presume the {{TransactionInfo}} should be sent only once for commit
> of single transaction, {{ConnectionStateTracker}} needs to clear state for
> the acknowledged transactions regardless of connection id in the transaction
> command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-6391) Memory leak with FailoverTransport when sending TX messages from MDB
Patrik Dudits created AMQ-6391:
--
Summary: Memory leak with FailoverTransport when sending TX
messages from MDB
Key: AMQ-6391
URL: https://issues.apache.org/jira/browse/AMQ-6391
Project: ActiveMQ
Issue Type: Bug
Reporter: Patrik Dudits
We observe memory leak in
{{FailoverTransport.stateTracker.connectionStates.transactions}} when using XA
Transactions in activemq-rar, sending message within same transaction and not
using {{useInboundSession}}.
In such constellation there are two connections enlisted within same
transaction. During commit the transaction manager will execute commit on one
of the resources, per JTA 1.2 section 3.3.1 ("(TransactionManager) ensures that
the same resource manager only receives one set of prepare-commit calls for
completing the target global transaction ".)
[TransactionContext|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L478]
will propagate the afterCommit to all contexts participating in same
transaction. However, this is not enough for {{ConnectionStateTracker}}, which
only reacts to [TransactionInfo
command|https://github.com/apache/activemq/blob/a65f5e7c2077e048a2664339f6425d73948d71ce/activemq-client/src/main/java/org/apache/activemq/TransactionContext.java#L469].
In effect, when two connection are enlisted in same transaction, just commands
of one of them is cleared upon commit, leading to memory leak.
Since I presume the {{TransactionInfo}} should be sent only once for commit of
single transaction, {{ConnectionStateTracker}} needs to clear state for the
acknowledged transactions regardless of connection id in the transaction
command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-6312) ObjectMessage's setTrustedPackages can only be applied via system property in resource adappter setting
[
https://issues.apache.org/jira/browse/AMQ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15316524#comment-15316524
]
Patrik Dudits edited comment on AMQ-6312 at 6/6/16 2:02 PM:
Stack trace for receiving MDBs for reference:
I've overriden RA's {{createConnectionFactory}} to set trusted packages.
{code}
javax.jms.JMSException: Failed to build body from content. Serializable class
not available to broker. Reason: java.lang.ClassNotFoundException: Forbidden
class ! This class is not trusted to be serialized as
ObjectMessage payload. Please take a look at
http://activemq.apache.org/objectmessage.html for more information on how to
configure trusted classes.
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
org.apache.activemq.command.ActiveMQObjectMessage.getObject(ActiveMQObjectMessage.java:208)
// ActiveMQObjectMessage has default trusted packages
at .onMessage()
at Payara EJB container, RAR adapter
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1041)
// session.connection has configured trusted packages
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
at
com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at
com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.ClassNotFoundException: Forbidden class ! This class is not trusted to be serialized as ObjectMessage payload.
Please take a look at http://activemq.apache.org/objectmessage.html for more
information on how to configure trusted classes.
at
org.apache.activemq.util.ClassLoadingAwareObjectInputStream.checkSecurity(ClassLoadingAwareObjectInputStream.java:112)
at
org.apache.activemq.util.ClassLoadingAwareObjectInputStream.resolveClass(ClassLoadingAwareObjectInputStream.java:57)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1613)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at
org.apache.activemq.command.ActiveMQObjectMessage.getObject(ActiveMQObjectMessage.java:206)
... 40 common frames omitted
{code}
was (Author: pdudits):
Stack trace for receiving MDBs for reference:
I've overriden RA's {{createConnectionFactory}} to set trusted packages.
{code}
javax.jms.JMSException: Failed to build body from content. Serializable class
not available to broker. Reason: java.lang.ClassNotFoundException: Forbidden
class ! This class is not trusted to be serialized as
ObjectMessage payload. Please take a look at
http://activemq.apache.org/objectmessage.html for more information on how to
configure trusted classes.
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
org.apache.activemq.command.ActiveMQObjectMessage.getObject(ActiveMQObjectMessage.java:208)
// ActiveMQObjectMessage has default trusted packages
at .onMessage()
at Payara EJB container, RAR adapter
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1041)
// session.connection has configured trusted packages
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
at
com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at
com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.ClassNotFoundException: Forbidden class ! This class is not trusted to be serialized as ObjectMessage payload.
Please take a look at http://activemq.apache.org/objectmessage.html for more
information on how to configure trusted classes.
at
org.apache.activemq.util.ClassLoadingAwareObjectInputStream.checkSecurity(ClassLoadingAwareObjectInputStream.java:112)
at
org.apache.activemq.util.ClassLoadingAwareObjectInputStream.resolveClass(ClassLoadingAwareObjectInputStream.java:57)
[jira] [Commented] (AMQ-6312) ObjectMessage's setTrustedPackages can only be applied via system property in resource adappter setting
[
https://issues.apache.org/jira/browse/AMQ-6312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15316524#comment-15316524
]
Patrik Dudits commented on AMQ-6312:
Stack trace for receiving MDBs for reference:
I've overriden RA's {{createConnectionFactory}} to set trusted packages.
{code}
javax.jms.JMSException: Failed to build body from content. Serializable class
not available to broker. Reason: java.lang.ClassNotFoundException: Forbidden
class ! This class is not trusted to be serialized as
ObjectMessage payload. Please take a look at
http://activemq.apache.org/objectmessage.html for more information on how to
configure trusted classes.
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:36)
at
org.apache.activemq.command.ActiveMQObjectMessage.getObject(ActiveMQObjectMessage.java:208)
// ActiveMQObjectMessage has default trusted packages
at .onMessage()
at Payara EJB container, RAR adapter
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:123)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:64)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:1041)
// session.connection has configured trusted packages
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:169)
at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:107)
at
com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.performWork(ThreadPoolImpl.java:497)
at
com.sun.corba.ee.impl.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:540)
Caused by: java.lang.ClassNotFoundException: Forbidden class ! This class is not trusted to be serialized as ObjectMessage payload.
Please take a look at http://activemq.apache.org/objectmessage.html for more
information on how to configure trusted classes.
at
org.apache.activemq.util.ClassLoadingAwareObjectInputStream.checkSecurity(ClassLoadingAwareObjectInputStream.java:112)
at
org.apache.activemq.util.ClassLoadingAwareObjectInputStream.resolveClass(ClassLoadingAwareObjectInputStream.java:57)
at
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1613)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at
org.apache.activemq.command.ActiveMQObjectMessage.getObject(ActiveMQObjectMessage.java:206)
... 40 common frames omitted
> ObjectMessage's setTrustedPackages can only be applied via system property in
> resource adappter setting
> ---
>
> Key: AMQ-6312
> URL: https://issues.apache.org/jira/browse/AMQ-6312
> Project: ActiveMQ
> Issue Type: Bug
>Affects Versions: 5.13.3
>Reporter: Patrik Dudits
>
> We're using ActiveMQ via resource adapter, and with upgrading post 5.12.0 we
> want to handle the trusted packages configuration via resource adapter rather
> than via system properties.
> This approach is not supported at all, because:
> # {{ActiveMQResourceAdapter}} does not expose {{setTrustedPackages}}
> # {{ActiveMQManagedConnectionFactory}} does not expose {{setTrustedPackages}}
> # Neither {{ServerSessionImpl}}, {{ActiveMQSession}} or
> {{MessageEndpointProxy}} set trusted packages on received
> {{ActiveMQObjectMessage}}
> The first two could be solved by adding the support into
> {{ActiveMQConnectionSupport}} by adding a property and applying
> trustedPackages in {{createConnectionFactory(ActiveMQConnectionRequestInfo,
> MessageActiveationSpec}}.
> However, for the third one I'm not sure on which level the change should be
> applied - either session should be enforcing connection's trusted packages,
> or {{ServerSessionImpl}} could do it in its {{beforeDelivery}} method. But I
> cannot think of use case where session should not be handling this in first
> place.
> Alternatively, {{ActiveMQObjectMessage}} could get the trusted packages list
> from its connection, which guarantees that deserialization rules of the
> connection are always applied, not only when {{ActiveMQConnectionConsumer}}
> is used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of browsers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15286935#comment-15286935
]
Patrik Dudits commented on AMQ-6209:
That is surprising, as I was starting with a failing test. I'll have to check
in different environments again. It may take few days to get back to this.
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of browsers
> ---
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
> Attachments: testOuput.tx
>
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of browsers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15285607#comment-15285607
]
Patrik Dudits commented on AMQ-6209:
Ok, so from the input, RMI registry port was already taken. I switched off
creation of JMX connector.
And for the actual cause of failure on JDK7, items in {{broker}} map were
returned in different order than on JDK 8, leading to incorrect failover URL to
be used in the test.
I updated the PR, please let me know if it works for you, I'll squash it right
after that.
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of browsers
> ---
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
> Attachments: testOuput.tx
>
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of browsers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284493#comment-15284493
]
Patrik Dudits commented on AMQ-6209:
I cleaned up the test a bit, however the functionality remains the same until I
will have a hint what might go wrong during restart - it doesn't seem to be
different from other such test cases.
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of browsers
> ---
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of browsers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284283#comment-15284283
]
Patrik Dudits edited comment on AMQ-6209 at 5/16/16 9:20 AM:
-
I will gladly comply, however I need to know what code did you run and in what
environment, as
[{{TwoBrokerVirtualTopicSelectorFailoverTest.java:137}}|https://github.com/apache/activemq/pull/174/files#diff-8a4e7ffbae789929bba4db6912813a58R137]
is start of multiline comment in the PR and the test passes for me on Windows,
JDK 1.8.0_45 and Maven 3.3.9.
Since that method is only used once, it might correspond to line 124. And it
could fail only if broker A failed to restart - a situation that is not
explicitly checked in the test ({{broker.waitUntilStarted}} returning
{{false}}). Is there more information in your test output why that happened?
was (Author: pdudits):
I will gladly comply, however I need to know what code did you run and in what
environment, as
[{{TwoBrokerVirtualTopicSelectorFailoverTest.java:137}}|https://github.com/apache/activemq/pull/174/files#diff-8a4e7ffbae789929bba4db6912813a58R137]
is start of multiline comment in the PR and the test passes for me on Windows,
JDK 1.8.0_45 and Maven 3.3.9.
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of browsers
> ---
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of browsers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15284283#comment-15284283
]
Patrik Dudits commented on AMQ-6209:
I will gladly comply, however I need to know what code did you run and in what
environment, as
[{{TwoBrokerVirtualTopicSelectorFailoverTest.java:137}}|https://github.com/apache/activemq/pull/174/files#diff-8a4e7ffbae789929bba4db6912813a58R137]
is start of multiline comment in the PR and the test passes for me on Windows,
JDK 1.8.0_45 and Maven 3.3.9.
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of browsers
> ---
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of brosers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15280573#comment-15280573
]
Patrik Dudits commented on AMQ-6209:
Yes, I just pushed updated PR.
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of brosers
> --
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of browsers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrik Dudits updated AMQ-6209:
---
Summary: Unmatched messages on consumer queues when using
SubQueueCacheSelectorPlugin in network of browsers (was: Unmatched messages on
consumer queues when using SubQueueCacheSelectorPlugin in network of brosers)
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of browsers
> ---
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6210) SubQueueCacheSelectorPlugin stores information on temporary queues
[ https://issues.apache.org/jira/browse/AMQ-6210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192907#comment-15192907 ] Patrik Dudits commented on AMQ-6210: I will provide a PR for this issue. > SubQueueCacheSelectorPlugin stores information on temporary queues > -- > > Key: AMQ-6210 > URL: https://issues.apache.org/jira/browse/AMQ-6210 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.13.2 >Reporter: Patrik Dudits > > SubQueueCacheSelectorPlugin stores selector data on temporary destinations. > I believe this is not necessary, as temporary destinations would cease to > exist when their creator disconnects, And the creator is also usually their > consumer in request-response scenarios. > This leads to ever growing cache file, and since this is just persisted > in-memory map, also to unnecessary memory consumption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-6210) SubQueueCacheSelectorPlugin stores information on temporary queues
Patrik Dudits created AMQ-6210: -- Summary: SubQueueCacheSelectorPlugin stores information on temporary queues Key: AMQ-6210 URL: https://issues.apache.org/jira/browse/AMQ-6210 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.13.2 Reporter: Patrik Dudits SubQueueCacheSelectorPlugin stores selector data on temporary destinations. I believe this is not necessary, as temporary destinations would cease to exist when their creator disconnects, And the creator is also usually their consumer in request-response scenarios. This leads to ever growing cache file, and since this is just persisted in-memory map, also to unnecessary memory consumption. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of brosers
[
https://issues.apache.org/jira/browse/AMQ-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192902#comment-15192902
]
Patrik Dudits commented on AMQ-6209:
I'll provide a test and a pull request
> Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin
> in network of brosers
> --
>
> Key: AMQ-6209
> URL: https://issues.apache.org/jira/browse/AMQ-6209
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.13.2
>Reporter: Patrik Dudits
>
> When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
> network of brokers, the queues start matching all messages after consumers
> failover between brokers.
> The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
> selector {{TRUE}} for connected demand subscription, and therefore will
> permanently match all messages even if actual consumer reconnects.
> Additionally, browsing the queue will also cause {{TRUE}} selector to be
> persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-6209) Unmatched messages on consumer queues when using SubQueueCacheSelectorPlugin in network of brosers
Patrik Dudits created AMQ-6209:
--
Summary: Unmatched messages on consumer queues when using
SubQueueCacheSelectorPlugin in network of brosers
Key: AMQ-6209
URL: https://issues.apache.org/jira/browse/AMQ-6209
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.13.2
Reporter: Patrik Dudits
When using SubQueueSelectorCachePlugin to preserve consumers' selectors in
network of brokers, the queues start matching all messages after consumers
failover between brokers.
The underlying reason is, that {{SubQueueSelectorCacheBroker}} would cache
selector {{TRUE}} for connected demand subscription, and therefore will
permanently match all messages even if actual consumer reconnects.
Additionally, browsing the queue will also cause {{TRUE}} selector to be
persisted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (AMQ-6036) Too trivial check in SubQueueSelectorCacheBroker.hasWildcards
[
https://issues.apache.org/jira/browse/AMQ-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15132489#comment-15132489
]
Patrik Dudits commented on AMQ-6036:
PR has been updated - added headers, rebased, and fixed one more corner case in
the parser (oh, those REs...).
> Too trivial check in SubQueueSelectorCacheBroker.hasWildcards
> -
>
> Key: AMQ-6036
> URL: https://issues.apache.org/jira/browse/AMQ-6036
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.12.1, 5.13.0
>Reporter: Patrik Dudits
>Assignee: Christopher L. Shannon
> Fix For: 5.14.0
>
>
> VirtualSelectorCache plugin cannot be reliably used when message selectors
> use e. g. literals with underscore like {{notificationType =
> 'NOTIFY_DELETE'}}.
> Full evaluation would need to walk the parsed selector, however the method
> should at least check for presence of {{LIKE}} case-insensitevely to return
> less false positives.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (AMQ-6036) Too trivial check in SubQueueSelectorCacheBroker.hasWildcards
[
https://issues.apache.org/jira/browse/AMQ-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrik Dudits updated AMQ-6036:
---
Component/s: Broker
Is there anything more I can do to get this merged?
> Too trivial check in SubQueueSelectorCacheBroker.hasWildcards
> -
>
> Key: AMQ-6036
> URL: https://issues.apache.org/jira/browse/AMQ-6036
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 5.12.1
>Reporter: Patrik Dudits
>
> VirtualSelectorCache plugin cannot be reliably used when message selectors
> use e. g. literals with underscore like {{notificationType =
> 'NOTIFY_DELETE'}}.
> Full evaluation would need to walk the parsed selector, however the method
> should at least check for presence of {{LIKE}} case-insensitevely to return
> less false positives.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (AMQ-6036) Too trivial check in SubQueueSelectorCacheBroker.hasWildcards
Patrik Dudits created AMQ-6036:
--
Summary: Too trivial check in
SubQueueSelectorCacheBroker.hasWildcards
Key: AMQ-6036
URL: https://issues.apache.org/jira/browse/AMQ-6036
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.12.1
Reporter: Patrik Dudits
VirtualSelectorCache plugin cannot be reliably used when message selectors use
e. g. literals with underscore like {{notificationType = 'NOTIFY_DELETE'}}.
Full evaluation would need to walk the parsed selector, however the method
should at least check for presence of {{LIKE}} case-insensitevely to return
less false positives.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
