[jira] [Resolved] (ACTIVEMQ6-6) Extract any JBoss SPI code replace with generic
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martyn Taylor resolved ACTIVEMQ6-6. --- Resolution: Fixed Extract any JBoss SPI code replace with generic --- Key: ACTIVEMQ6-6 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-6 Project: Apache ActiveMQ 6 Issue Type: Improvement Reporter: Martyn Taylor Fix For: 6.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: ActiveMQ 6 - TomEE integration
On 05/01/15 12:25, John D. Ament wrote: If you look at the branch as of late yesterday, you'll see that it mostly works which is pretty cool. I'm now able to write a message and see that the the RA tries to pass it to the message listener. ActiveMQ seems to go into a weird loop here, haven't looked much closer yet. There's a couple of things I'd like to recommend. - Can TransactionManagerLookup be passed in via configuration, in addition to a serviceloader? So if it's not configured you leverage a service loader to resolve it? By passing by configuration, Do you mean allowing the TransactionManagerLocator class to be configured. Something along the lines of transaction-manager-locatororg.foo.TransactionManagerImplemention/.. - ActiveMQ previously had a feature where the first time a destination was written to it was created. TomEE/OpenEJB seem to make heavy use of that, at least within tests. I would imagine the users do as well. Any chance that can be ported in? Currently AMQ6 will throw an exception if it doesn't exist. This is something we are looking at. We have a JIRA for this here: https://issues.apache.org/jira/browse/ACTIVEMQ6-13?jql=project%20%3D%20ACTIVEMQ6 John On Sat Jan 03 2015 at 6:59:14 PM John D. Ament johndam...@apache.org wrote: Yeah, I would imagine the final pass will make everything in Configuration an option to the RA. For now, I'm just bypassing things until I get a good grip on what's being passed in to the properties. For the scope of this (a POC), I ripped out AMQ 5.10 and dropped in 6. I believe things are still up in the air, but I know there's a goal for JMS 2 support in TomEE 2 and right now it doesn't make sense to try to backport the JMS 2 APIs to the ActiveMQ codebase. John On Sat Jan 03 2015 at 6:02:47 PM Clebert Suconic clebert.suco...@gmail.com wrote: You Probably need to configure security properly and pass the proper Principal? I will take a look on monday... I'm at the end of my vacations now and I won't be able to work over the weekend... Again... good stuff... BTW: Are you totally replacing ActiveMQ by 6 or you are making it optional? On Sat, Jan 3, 2015 at 2:19 PM, John D. Ament johndam...@apache.org wrote: Little more info. Got past this part. Then hit an auth issue, turned off auth for now and I at least see the connections making it (woo hoo!!). It looks like it passes back a proxy wrapper to the session, and not the session itself. It looks like OpenEJB and ActiveMQ are both trying to handle the closing of the session automatically. https://github.com/apache/tomee/blob/develop/container/opene jb-core/src/main/java/org/apache/openejb/resource/AutoCo nnectionTracker.java So ummm need to think about this a bit more. John On Sat Jan 03 2015 at 1:29:31 PM John D. Ament johndam...@apache.org wrote: Clebert, On Sat Jan 03 2015 at 1:11:57 PM Clebert Suconic clebert.suco...@gmail.com wrote: That's great stuff you're doing... Is there a branch we could try this? Sure, you can find it here: https://github.com/johnament/tomee/tree/activemq-6 You can see the test is called AMQXASupportTest, where I'm just trying to go through the steps that would bootstrap the RA. It's in the openejb-core module, the only things I've poked at thus far are around which classes are being invoked since there's lots of new packages and classes floating around (obviously). FWIW I had thought to use a similar approach I took last time I did an embedded HornetQ type solution, however that was an early 2.1/2.2 thing, and it looks like the 2.4 code base was a bit different for the non-JMS pieces. Perhaps there are dependencies that would need to be installed, and old dependencies we still need to clear from the codebase? Did you look at that? I've thought about classloader issues, but I don't think that's the case yet. The fact that I'm seeing AMQ start up means that the code to boot the RA is working, it's simply not able to find the InVM connection that it's expecting. All maven dependencies were updated and locally I'm building off this branch: https://github.com/johnament/activemq-6/tree/geronimo-spec-jar but I don't think that makes much difference. Now it could also be that I was way off on my guesses for what the new classes are, but comparing the classes I picked from 6 to what TomEE used in 5.10 they appear to serve the same function. The only thing special about TomEE's RA (which extended AMQ 5.10's) was that they used the JDBC store for messages. For now that's not an issue for me so I avoided the sub-class for now. John On Sat, Jan 3, 2015 at 11:23 AM, John D. Ament johndam...@apache.org wrote: I'm resending this as I had my emails messed up. Sorry for any moderation issues. On Sat Jan 03 2015 at 11:06:43 AM John D. Ament johndam...@apache.org wrote: Ok, so got a little bit further. I see the broker starting with the in vm connector. 659 [main] DEBUG org.apache.activemq.ra
Re: [DISCUSS] Renaming trunk to master
+1, master is the norm, no matter which Git workflow you use. On Mon, Jan 5, 2015 at 1:27 PM, Hadrian Zbarcea hzbar...@gmail.com wrote: It's a bit confusing, a leftover from the svn days. I think the rename was supposed to happen but it was somehow overlooked. Any objection to rename? Hadrian
Re: [DISCUSS] Renaming trunk to master
+1 for the rename. Using master is typical and this is definitely a change now made by infra during migrations, based on experience of migrating a couple of things into Git repos at Qpid recently. On 5 January 2015 at 18:27, Hadrian Zbarcea hzbar...@gmail.com wrote: It's a bit confusing, a leftover from the svn days. I think the rename was supposed to happen but it was somehow overlooked. Any objection to rename? Hadrian
Re: [VOTE] Release Apache.NMS API 1.7.0
+1 Regards -- Dejan Bosanac -- Red Hat, Inc. dbosa...@redhat.com Twitter: @dejanb Blog: http://sensatic.net ActiveMQ in Action: http://www.manning.com/snyder/ On Tue, Jan 6, 2015 at 6:58 AM, Claus Ibsen claus.ib...@gmail.com wrote: +1 On Mon, Jan 5, 2015 at 3:59 PM, Timothy Bish tabish...@gmail.com wrote: Hello This is a call for a vote on the release of the Apache.NMS API v1.7.0. This package contains the API for the various Apache.NMS client along with utility classes and unit test cases against the abstract NMS API. This version of the API will be the basis for the next set of NMS client releases including Apache.NMS.ActiveMQ and Apache.NMS.Stomp etc. Changes in this version include: * Added IDisposable as a base of IDestination. * Added some improvements to the Unit tests framework. * Added some new provider names (AMQP and MQTT) to allow for future clients. The binaries and source bundles for the Release Candidate can be found here: [ http://people.apache.org/~tabish/nms-1.7.x ] The Wiki Page for this release is here: [ http://activemq.apache.org/nms/apachenms-api-v170.html ] Please cast your votes (the vote will be open for 72 hrs): [ ] +1 Release the source as Apache NMS API 1.7.0 [ ] -1 (provide specific comments) Here's my +1 Regards, Tim -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/ -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
Re: [DISCUSS] Renaming trunk to master
+1 Maybe we should wait with the rename until we have 5.11.0 released (there’s some work involved like reconfiguring jenkins and stuff, so it'll delay release) Regards -- Dejan Bosanac -- Red Hat, Inc. dbosa...@redhat.com Twitter: @dejanb Blog: http://sensatic.net ActiveMQ in Action: http://www.manning.com/snyder/ On Tue, Jan 6, 2015 at 1:44 PM, Robbie Gemmell robbie.gemm...@gmail.com wrote: +1 for the rename. Using master is typical and this is definitely a change now made by infra during migrations, based on experience of migrating a couple of things into Git repos at Qpid recently. On 5 January 2015 at 18:27, Hadrian Zbarcea hzbar...@gmail.com wrote: It's a bit confusing, a leftover from the svn days. I think the rename was supposed to happen but it was somehow overlooked. Any objection to rename? Hadrian
[GitHub] activemq-6 pull request: Fix failing RA OutgoingConnectionTests
GitHub user mtaylor opened a pull request: https://github.com/apache/activemq-6/pull/54 Fix failing RA OutgoingConnectionTests Some of the outgoing connection tests require a dummy transaction manager to setup a fake transaction. The default transaction manager is set to the JBoss TX manager and so the tests were failing. This patch split the OutgoingConnectionTest into ones that require a real TM manager vs Dummy TM Manager. . You can merge this pull request into a Git repository by running: $ git pull https://github.com/mtaylor/activemq-6 fixOutgoingConnectionTest Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-6/pull/54.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #54 commit b9ad78e29c1deaef54e60912503a887de092594c Author: Martyn Taylor mtay...@redhat.com Date: 2015-01-06T13:31:29Z Fix failing RA OutgoingConnectionTests Some of the outgoing connection tests require a dummy transaction manager to setup a fake transaction. The default transaction manager is set to the JBoss TX manager and so the tests were failing. This patch split the OutgoingConnectionTest into ones that require a real TM manager vs Dummy TM Manager. . --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: [CANCEL][VOTE] Release Apache ActiveMQ 5.10.1 (2nd attempt)
The STOMP tests passed on the trunk. Ran into another problem which I believe is being discussed in the 5.11 release thread. I'll see if I can find what's different in the stop tests. -- View this message in context: http://activemq.2283324.n4.nabble.com/VOTE-Release-Apache-ActiveMQ-5-10-1-2nd-attempt-tp4689263p4689582.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [CANCEL][VOTE] Release Apache ActiveMQ 5.10.1 (2nd attempt)
I ran a build without tests no problem. Running unit tests, I am seeing problems with Stomp tests. Right now, I'm re-running the build against the trunk to see if the same errors occur. Honestly, I am so used to being in the habit of building without tests in ActiveMQ because of inconsistent results and excessive test time. -- View this message in context: http://activemq.2283324.n4.nabble.com/VOTE-Release-Apache-ActiveMQ-5-10-1-2nd-attempt-tp4689263p4689580.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [VOTE] Release Apache.NMS API 1.7.0
+1 (non-binding) -- View this message in context: http://activemq.2283324.n4.nabble.com/VOTE-Release-Apache-NMS-API-1-7-0-tp4689440p4689579.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Resolved] (AMQ-5481) Trace logs in MQTT Protocol Converter
[ https://issues.apache.org/jira/browse/AMQ-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-5481. --- Resolution: Fixed Patch applied with some tweaks Trace logs in MQTT Protocol Converter - Key: AMQ-5481 URL: https://issues.apache.org/jira/browse/AMQ-5481 Project: ActiveMQ Issue Type: Improvement Components: MQTT Affects Versions: 5.11.0 Reporter: AR Assignee: Timothy Bish Priority: Minor Labels: MQTT Fix For: 5.11.0 Attachments: MQTTProtocolConverter.java.tracepatch Adding trace messages in MQTT Protocol Converter for easier debugging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (AMQ-5481) Trace logs in MQTT Protocol Converter
[ https://issues.apache.org/jira/browse/AMQ-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reassigned AMQ-5481: - Assignee: Timothy Bish Trace logs in MQTT Protocol Converter - Key: AMQ-5481 URL: https://issues.apache.org/jira/browse/AMQ-5481 Project: ActiveMQ Issue Type: Improvement Components: MQTT Affects Versions: 5.11.0 Reporter: AR Assignee: Timothy Bish Priority: Minor Labels: MQTT Fix For: 5.11.0 Attachments: MQTTProtocolConverter.java.tracepatch Adding trace messages in MQTT Protocol Converter for easier debugging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5481) Trace logs in MQTT Protocol Converter
[ https://issues.apache.org/jira/browse/AMQ-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-5481: -- Fix Version/s: 5.11.0 Trace logs in MQTT Protocol Converter - Key: AMQ-5481 URL: https://issues.apache.org/jira/browse/AMQ-5481 Project: ActiveMQ Issue Type: Improvement Components: MQTT Affects Versions: 5.11.0 Reporter: AR Assignee: Timothy Bish Priority: Minor Labels: MQTT Fix For: 5.11.0 Attachments: MQTTProtocolConverter.java.tracepatch Adding trace messages in MQTT Protocol Converter for easier debugging. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5508) Broker shutdown race condition leads to IllegalStateException: Timer already cancelled
Pero Atanasov created AMQ-5508:
--
Summary: Broker shutdown race condition leads to
IllegalStateException: Timer already cancelled
Key: AMQ-5508
URL: https://issues.apache.org/jira/browse/AMQ-5508
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.10.0
Reporter: Pero Atanasov
Priority: Minor
This issue is seen on the surface with the broker failing to remove a consumer:
2014-12-19 10:45:42,586 | WARN | Failed to remove consumer:
ID:hack-34927-1419007505006-2:3:0:0 |
org.apache.activemq.broker.TransportConnection | ActiveMQ
BrokerService[broker0] Task-6
java.lang.IllegalStateException: Timer already cancelled.
The full stack trace [STACK_TRACE] will be specified at the end of this report.
In this case, the race condition is exposed via some of the AdvisoryBroker code
while trying to send an advisory message as part of the consumer/producer
addition/removal code. Below are excerpts of code to explain this race
condition:
activemq-broker/src/main/java/org/apache/activemq/advisory/AdvisoryBroker.java
Lines 605 - 637 [in fireAdvisory(...)]
if (getBrokerService().isStarted()) {
// code to create and populate an advisory message
next.send(producerExchange, advisoryMessage);
// send will trigger destination creation/addition for this advisory
message topic
}
However, it can easily happen that a client (consumer or producer) connects and
is added _before_ getBrokerService().isStarted() is true, so in that case, the
boolean expression in the block above will evaluate to false and hence skip the
entire advisory message send and create/add destination process. At this point,
the consumer/producer destination does not have its advisory message
destination created. If no other consumer/producer connects on the same
destination until the broker is shutting down, then no advisory destination
pairing will be created for that consumer/producer. When the broker starts the
shutdown process, the event that will trigger an advisory message will be the
removal of a consumer/producer as part of the TransportConnection stopping
process. The sequence of calls with line numbers can be seen within the
STACK_TRACE.
Back to the above specified code block, when the broker is shutting down, the
broker is well started. Then, the boolean expression will evaluate to true and
hence proceed with the advisory message creation/sending and destination
cration/addition process. However, in the meantime, as part of the shutdown
process, the Scheduler timer is being cancelled. Consider the following blocks
of code:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
Lines 756 - 761 [in stop()]
// for each service
stopper.stop(service);
activemq-client/src/main/java/org/apache/activemq/util/ServiceSupport.java
Lines 67 - 84 [in stop()]
if (stopped.compareAndSet(false, true)) {
... some code ...
doStop(stopper);
... some code ...
}
activemq-client/src/main/java/org/apache/activemq/thread/Scheduler.java
Lines 69 - 71 [in doStop(...)]
if (this.timer != null) {
this.timer.cancel();
}
At this point, the timer is cancelled. Now, back to the thread removing the
consumer. From the STACK_TRACE, it can be seen that after many calls related to
the advisory message destination creation, it ends up in AbstractRegion’s
addDestination method.
activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java
Lines 132 - 145 [in addDestination(...)]
if (dest == null) {
... some code ...
dest = createDestination(context, destination);
... some code ...
dest.start();
... some code ...
}
As it can be seen in the STACK_TRACE below, dest.start() call will trigger the
need for a timer to be scheduled on the same timer that has already been
cancelled. Some debug prints to confirm the race condition:
1. Fail to send advisory message for this consumer advisory topic because
getBrokerService().isStarted() is false:
2015-01-06 08:49:26,215 | INFO | patanasov: from AdvisoryBroker fireAdvisory
would have sent advisoryMessage: topic
ActiveMQ.Advisory.Consumer.Queue.2015.01.06-08.23.00.16401 |
org.apache.activemq.advisory.AdvisoryBroker
2. Broker shutting down and cancelling timer:
2015-01-06 08:49:43,602 | INFO | Apache ActiveMQ 5.10.0 (broker0,
ID:host-40197-1420555763149-0:1) is shutting down |
org.apache.activemq.broker.BrokerService | ActiveMQ ShutdownHook
2015-01-06 08:49:43,603 | INFO | patanasov: from ServiceSupport calling
doStop(stopper) | org.apache.activemq.util.ServiceSupport | ActiveMQ
ShutdownHook
2015-01-06 08:49:43,603 | INFO | patanasov: from Scheduler
doStop(ServiceStopper stopper) calling this.timer.cancel(): timer
java.util.Timer@7df33bb0 | org.apache.activemq.thread.Scheduler | ActiveMQ
ShutdownHook
3. Adding destination and
[jira] [Updated] (AMQ-5508) Broker shutdown race condition leads to IllegalStateException: Timer already cancelled
[
https://issues.apache.org/jira/browse/AMQ-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pero Atanasov updated AMQ-5508:
---
Attachment: AMQ5508.patch
Patch to fix raised issue.
NOTE: In the stack trace, the exception happens in
Scheduler.schedualPeriodically, but this function has been deprecated.
Therefore, the patch is now applied within Scheduler.executePeriodically since
that's what is being called now from Topic.start().
The fix involves checking if the timer has already been called stop on before
calling schedule on it. That way no calls are made if it has already been
cancelled.
Broker shutdown race condition leads to IllegalStateException: Timer already
cancelled
Key: AMQ-5508
URL: https://issues.apache.org/jira/browse/AMQ-5508
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.10.0
Reporter: Pero Atanasov
Priority: Minor
Attachments: AMQ5508.patch
This issue is seen on the surface with the broker failing to remove a
consumer:
2014-12-19 10:45:42,586 | WARN | Failed to remove consumer:
ID:hack-34927-1419007505006-2:3:0:0 |
org.apache.activemq.broker.TransportConnection | ActiveMQ
BrokerService[broker0] Task-6
java.lang.IllegalStateException: Timer already cancelled.
The full stack trace [STACK_TRACE] will be specified at the end of this
report.
In this case, the race condition is exposed via some of the AdvisoryBroker
code while trying to send an advisory message as part of the
consumer/producer addition/removal code. Below are excerpts of code to
explain this race condition:
activemq-broker/src/main/java/org/apache/activemq/advisory/AdvisoryBroker.java
Lines 605 - 637 [in fireAdvisory(...)]
if (getBrokerService().isStarted()) {
// code to create and populate an advisory message
next.send(producerExchange, advisoryMessage);
// send will trigger destination creation/addition for this advisory
message topic
}
However, it can easily happen that a client (consumer or producer) connects
and is added _before_ getBrokerService().isStarted() is true, so in that
case, the boolean expression in the block above will evaluate to false and
hence skip the entire advisory message send and create/add destination
process. At this point, the consumer/producer destination does not have its
advisory message destination created. If no other consumer/producer connects
on the same destination until the broker is shutting down, then no advisory
destination pairing will be created for that consumer/producer. When the
broker starts the shutdown process, the event that will trigger an advisory
message will be the removal of a consumer/producer as part of the
TransportConnection stopping process. The sequence of calls with line numbers
can be seen within the STACK_TRACE.
Back to the above specified code block, when the broker is shutting down, the
broker is well started. Then, the boolean expression will evaluate to true
and hence proceed with the advisory message creation/sending and destination
cration/addition process. However, in the meantime, as part of the shutdown
process, the Scheduler timer is being cancelled. Consider the following
blocks of code:
activemq-broker/src/main/java/org/apache/activemq/broker/BrokerService.java
Lines 756 - 761 [in stop()]
// for each service
stopper.stop(service);
activemq-client/src/main/java/org/apache/activemq/util/ServiceSupport.java
Lines 67 - 84 [in stop()]
if (stopped.compareAndSet(false, true)) {
... some code ...
doStop(stopper);
... some code ...
}
activemq-client/src/main/java/org/apache/activemq/thread/Scheduler.java
Lines 69 - 71 [in doStop(...)]
if (this.timer != null) {
this.timer.cancel();
}
At this point, the timer is cancelled. Now, back to the thread removing the
consumer. From the STACK_TRACE, it can be seen that after many calls related
to the advisory message destination creation, it ends up in AbstractRegion’s
addDestination method.
activemq-broker/src/main/java/org/apache/activemq/broker/region/AbstractRegion.java
Lines 132 - 145 [in addDestination(...)]
if (dest == null) {
... some code ...
dest = createDestination(context, destination);
... some code ...
dest.start();
... some code ...
}
As it can be seen in the STACK_TRACE below, dest.start() call will trigger
the need for a timer to be scheduled on the same timer that has already been
cancelled. Some debug prints to confirm the race condition:
1. Fail to send advisory message for this consumer advisory topic because
getBrokerService().isStarted() is false:
2015-01-06 08:49:26,215 | INFO | patanasov: from AdvisoryBroker fireAdvisory
would have
Re: [VOTE] Release Apache.NMS API 1.7.0
+1 On 5 January 2015 at 14:59, Timothy Bish tabish...@gmail.com wrote: Hello This is a call for a vote on the release of the Apache.NMS API v1.7.0. This package contains the API for the various Apache.NMS client along with utility classes and unit test cases against the abstract NMS API. This version of the API will be the basis for the next set of NMS client releases including Apache.NMS.ActiveMQ and Apache.NMS.Stomp etc. Changes in this version include: * Added IDisposable as a base of IDestination. * Added some improvements to the Unit tests framework. * Added some new provider names (AMQP and MQTT) to allow for future clients. The binaries and source bundles for the Release Candidate can be found here: [ http://people.apache.org/~tabish/nms-1.7.x ] The Wiki Page for this release is here: [ http://activemq.apache.org/nms/apachenms-api-v170.html ] Please cast your votes (the vote will be open for 72 hrs): [ ] +1 Release the source as Apache NMS API 1.7.0 [ ] -1 (provide specific comments) Here's my +1 Regards, Tim -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com skype: tabish121 | twitter: @tabish121 blog: http://timbish.blogspot.com/
[jira] [Commented] (ACTIVEMQ6-64) Queue.totalIterator() is showing Messages twice when batch of messages pushed address over page threshold
[ https://issues.apache.org/jira/browse/ACTIVEMQ6-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14266389#comment-14266389 ] ASF GitHub Bot commented on ACTIVEMQ6-64: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-6/pull/53 Queue.totalIterator() is showing Messages twice when batch of messages pushed address over page threshold - Key: ACTIVEMQ6-64 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-64 Project: Apache ActiveMQ 6 Issue Type: Bug Reporter: Martyn Taylor Assignee: clebert suconic When sending a batch of messages using the core protocol. i.e. performing producer.send(message); multiple times then calling session.commit(). The messages are paged twice. This happens when the number of messages in the batch pushes the address over it's max allocated memory and initialises paging on the address. If the messages are committed after the paging has started this bug does not surface, nor does it occur if the total messages in the batch do not push the address in paging mode. For example. I have an address testAddress backed up by a queue testQueue. The max memory on the address is set to 10MB. If there are no messages in the queue, hence the total memory usage of the address is 10MB and I send 20 x messages of 1MB, the call session.commit(). The messages that exceed the memory limit are paged twice. Messages 1 - 10 stay in memory, messages 11 - 20 are paged twice. This does not happen when the address is already in paging mode. If the address is in paging mode before we send the 20 messages, the server behaves as expected and pages all 20 messages once. I have created a test to show this behaviour here: https://github.com/mtaylor/activemq-6/commit/b7bee77bcefb12c4b104c0beb3f4dc9aab545f6b -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Jenkins build became unstable: ActiveMQ » ActiveMQ :: LevelDB Store #1583
See https://builds.apache.org/job/ActiveMQ/org.apache.activemq$activemq-leveldb-store/1583/
[GitHub] activemq-6 pull request: ACTIVEMQ6-64 Messages duplicated during S...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-6/pull/53 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
