[jira] [Commented] (AMQ-5549) Shared Filesystem Master/Slave using NFSv4 allows both brokers become active at the same time
[ https://issues.apache.org/jira/browse/AMQ-5549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296517#comment-14296517 ] Heikki Manninen commented on AMQ-5549: -- This seems to be related: https://issues.apache.org/jira/browse/AMQ-4705 Will try with the following configuration: > Shared Filesystem Master/Slave using NFSv4 allows both brokers become active > at the same time > - > > Key: AMQ-5549 > URL: https://issues.apache.org/jira/browse/AMQ-5549 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Message Store >Affects Versions: 5.10.1 > Environment: - CentOS Linux 6 > - OpenJDK 1.7 > - ActiveMQ 5.10.1 >Reporter: Heikki Manninen >Priority: Critical > > Identical ActiveMQ master and slave brokers are installed on CentOS Linux 6 > virtual machines. There is a third virtual machine (also CentOS 6) providing > an NFSv4 share for the brokers KahaDB. > Both brokers are started and the master broker acquires file lock on the lock > file and the slave broker sits in a loop and waits for a lock as expected. > Also changing brokers work as expected. > Once the network connection of the NFS server is disconnected both master and > slave NFS mounts block and slave broker stops logging file lock re-tries. > After a short while after bringing the network connection back the mounts > come back and the slave broker is able to acquire the lock simultaneously. > Both brokers accept client connections. > In this situation it is also possible to stop and start both individual > brokers many times and they are always able to acquire the lock even if the > other one is already running. Only after stopping both brokers and starting > them again is the situation back to normal. > * NFS server: > - CentOS Linux 6 > - NFS v4 export options: rw,sync > - NFS v4 grace time 45 seconds > - NFS v4 lease time 10 seconds > * NFS client: > - CentOS Linux 6 > - NFS mount options: nfsvers=4,proto=tcp,hard,wsize=65536,rsize=65536 > * ActiveMQ configuration (otherwise default): > > > > > > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5549) Shared Filesystem Master/Slave using NFSv4 allows both brokers become active at the same time
Heikki Manninen created AMQ-5549: Summary: Shared Filesystem Master/Slave using NFSv4 allows both brokers become active at the same time Key: AMQ-5549 URL: https://issues.apache.org/jira/browse/AMQ-5549 Project: ActiveMQ Issue Type: Bug Components: Broker, Message Store Affects Versions: 5.10.1 Environment: - CentOS Linux 6 - OpenJDK 1.7 - ActiveMQ 5.10.1 Reporter: Heikki Manninen Priority: Critical Identical ActiveMQ master and slave brokers are installed on CentOS Linux 6 virtual machines. There is a third virtual machine (also CentOS 6) providing an NFSv4 share for the brokers KahaDB. Both brokers are started and the master broker acquires file lock on the lock file and the slave broker sits in a loop and waits for a lock as expected. Also changing brokers work as expected. Once the network connection of the NFS server is disconnected both master and slave NFS mounts block and slave broker stops logging file lock re-tries. After a short while after bringing the network connection back the mounts come back and the slave broker is able to acquire the lock simultaneously. Both brokers accept client connections. In this situation it is also possible to stop and start both individual brokers many times and they are always able to acquire the lock even if the other one is already running. Only after stopping both brokers and starting them again is the situation back to normal. * NFS server: - CentOS Linux 6 - NFS v4 export options: rw,sync - NFS v4 grace time 45 seconds - NFS v4 lease time 10 seconds * NFS client: - CentOS Linux 6 - NFS mount options: nfsvers=4,proto=tcp,hard,wsize=65536,rsize=65536 * ActiveMQ configuration (otherwise default): -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5540) KahaDB can't fail over to the slave if the master is unable to write to disk
[ https://issues.apache.org/jira/browse/AMQ-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296454#comment-14296454 ] Anuj Khandelwal edited comment on AMQ-5540 at 1/29/15 6:41 AM: --- I have updated the request with more details. Please check once. was (Author: anujkhandelwal): I have updated the details. Can you check now ? > KahaDB can't fail over to the slave if the master is unable to write to disk > > > Key: AMQ-5540 > URL: https://issues.apache.org/jira/browse/AMQ-5540 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Message Store >Affects Versions: 5.10.0 > Environment: Using Master-slave topology with shared kahadb. > Using KahaDB on NFS. >Reporter: Anuj Khandelwal > Attachments: ActiveMQ_config.xml, Logs.txt > > > This is coming from > http://activemq.2283324.n4.nabble.com/kahadb-corruption-quot-Checkpoint-failed-java-io-IOException-Input-output-error-quot-td4690378.html#a4690442 > . > Scenario : We had some failure on filer because of which applications > (ActiveMQ) was not able to read/write on kahadb. I have attached the logs to > see the details. Master broker was not completely killed. Master has stopped > it's transport connectors and plugins but it didn't release it's lock from > the kahadb. I have checked from "ps" command that master broker was running. > And since master didn't release the lock on kahadb, slave broker was not able > to acquire the lock. > Master broker should shutdown properly in such cases and let the slave take > over the persistence store. > Thanks, > Anuj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5540) KahaDB can't fail over to the slave if the master is unable to write to disk
[ https://issues.apache.org/jira/browse/AMQ-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296454#comment-14296454 ] Anuj Khandelwal commented on AMQ-5540: -- I have updated the details. Can you check now ? > KahaDB can't fail over to the slave if the master is unable to write to disk > > > Key: AMQ-5540 > URL: https://issues.apache.org/jira/browse/AMQ-5540 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Message Store >Affects Versions: 5.10.0 > Environment: Using Master-slave topology with shared kahadb. > Using KahaDB on NFS. >Reporter: Anuj Khandelwal > Attachments: ActiveMQ_config.xml, Logs.txt > > > This is coming from > http://activemq.2283324.n4.nabble.com/kahadb-corruption-quot-Checkpoint-failed-java-io-IOException-Input-output-error-quot-td4690378.html#a4690442 > . > Scenario : We had some failure on filer because of which applications > (ActiveMQ) was not able to read/write on kahadb. I have attached the logs to > see the details. Master broker was not completely killed. Master has stopped > it's transport connectors and plugins but it didn't release it's lock from > the kahadb. I have checked from "ps" command that master broker was running. > And since master didn't release the lock on kahadb, slave broker was not able > to acquire the lock. > Master broker should shutdown properly in such cases and let the slave take > over the persistence store. > Thanks, > Anuj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5540) KahaDB can't fail over to the slave if the master is unable to write to disk
[ https://issues.apache.org/jira/browse/AMQ-5540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anuj Khandelwal updated AMQ-5540: - Description: This is coming from http://activemq.2283324.n4.nabble.com/kahadb-corruption-quot-Checkpoint-failed-java-io-IOException-Input-output-error-quot-td4690378.html#a4690442 . Scenario : We had some failure on filer because of which applications (ActiveMQ) was not able to read/write on kahadb. I have attached the logs to see the details. Master broker was not completely killed. Master has stopped it's transport connectors and plugins but it didn't release it's lock from the kahadb. I have checked from "ps" command that master broker was running. And since master didn't release the lock on kahadb, slave broker was not able to acquire the lock. Master broker should shutdown properly in such cases and let the slave take over the persistence store. Thanks, Anuj was: This is coming from http://activemq.2283324.n4.nabble.com/kahadb-corruption-quot-Checkpoint-failed-java-io-IOException-Input-output-error-quot-td4690378.html#a4690442 . KahaDB can't fail over to the slave if the master is unable to write to disk when it shuts down (because it couldn't write to disk). KahaDB should be able to detect such failures and allow slave broker to acquire the lock. Thanks, Anuj > KahaDB can't fail over to the slave if the master is unable to write to disk > > > Key: AMQ-5540 > URL: https://issues.apache.org/jira/browse/AMQ-5540 > Project: ActiveMQ > Issue Type: Bug > Components: Broker, Message Store >Affects Versions: 5.10.0 > Environment: Using Master-slave topology with shared kahadb. > Using KahaDB on NFS. >Reporter: Anuj Khandelwal > Attachments: ActiveMQ_config.xml, Logs.txt > > > This is coming from > http://activemq.2283324.n4.nabble.com/kahadb-corruption-quot-Checkpoint-failed-java-io-IOException-Input-output-error-quot-td4690378.html#a4690442 > . > Scenario : We had some failure on filer because of which applications > (ActiveMQ) was not able to read/write on kahadb. I have attached the logs to > see the details. Master broker was not completely killed. Master has stopped > it's transport connectors and plugins but it didn't release it's lock from > the kahadb. I have checked from "ps" command that master broker was running. > And since master didn't release the lock on kahadb, slave broker was not able > to acquire the lock. > Master broker should shutdown properly in such cases and let the slave take > over the persistence store. > Thanks, > Anuj -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5503) Make init script more reliable
[ https://issues.apache.org/jira/browse/AMQ-5503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296433#comment-14296433 ] Jean-Baptiste Onofré commented on AMQ-5503: --- I have to check but admin bat script provides functions not available on activemq bat script. > Make init script more reliable > -- > > Key: AMQ-5503 > URL: https://issues.apache.org/jira/browse/AMQ-5503 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.10.0 > Environment: Unix/Linux >Reporter: Marc Schöchlin > > The Activemq init script received with AMQ-5378 some changes which improve > the quality of the init script. This ticket addresses further improvements. > - Add a shellscript testsuite to ease the verification of the proper function > on various unix platforms (Linux, MacOS, ...) > - Make the shellscript code more reliable > - Improve usability for administrative users -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5548) Virtual Destination related statistics which user can log
Pradeep Bansal created AMQ-5548: --- Summary: Virtual Destination related statistics which user can log Key: AMQ-5548 URL: https://issues.apache.org/jira/browse/AMQ-5548 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: Pradeep Bansal Priority: Trivial I am using Virtual destination in my setup and was looking for any statistics broker can provide about them, but am unable to find so. It would be nice if we have this feature as then we can have a check on what kind of usage and performance impact these Virtual Destinations create. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5503) Make init script more reliable
[ https://issues.apache.org/jira/browse/AMQ-5503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263841#comment-14263841 ] Marc Schöchlin edited comment on AMQ-5503 at 1/29/15 5:32 AM: -- waiting for feedback or a successful merge was (Author: scoopex): see previous comment > Make init script more reliable > -- > > Key: AMQ-5503 > URL: https://issues.apache.org/jira/browse/AMQ-5503 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.10.0 > Environment: Unix/Linux >Reporter: Marc Schöchlin > > The Activemq init script received with AMQ-5378 some changes which improve > the quality of the init script. This ticket addresses further improvements. > - Add a shellscript testsuite to ease the verification of the proper function > on various unix platforms (Linux, MacOS, ...) > - Make the shellscript code more reliable > - Improve usability for administrative users -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (AMQ-5503) Make init script more reliable
[ https://issues.apache.org/jira/browse/AMQ-5503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14263840#comment-14263840 ] Marc Schöchlin edited comment on AMQ-5503 at 1/29/15 5:31 AM: -- Pull request available: https://github.com/apache/activemq/pull/55 was (Author: scoopex): Patch available: https://github.com/apache/activemq/pull/55 > Make init script more reliable > -- > > Key: AMQ-5503 > URL: https://issues.apache.org/jira/browse/AMQ-5503 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.10.0 > Environment: Unix/Linux >Reporter: Marc Schöchlin > > The Activemq init script received with AMQ-5378 some changes which improve > the quality of the init script. This ticket addresses further improvements. > - Add a shellscript testsuite to ease the verification of the proper function > on various unix platforms (Linux, MacOS, ...) > - Make the shellscript code more reliable > - Improve usability for administrative users -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5533) Update Mac support for activemq-admin script
[ https://issues.apache.org/jira/browse/AMQ-5533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296401#comment-14296401 ] Marc Schöchlin commented on AMQ-5533: - "activemq-admin" is not needed anymore, because all of its functionality is already integrated in the "activemq" script. I spent some time to improve the compatibility of the "activemq" on several unix platforms (also macosx). My last pull request at AMQ-5503 also contains a testsuite which helps to validate the proper function on macosx. I hope to get feedback or a successful merge soon... > Update Mac support for activemq-admin script > > > Key: AMQ-5533 > URL: https://issues.apache.org/jira/browse/AMQ-5533 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.10.0 > Environment: OSX Yosemite >Reporter: Michael Rimov > Labels: patch, scripts > Attachments: activemq-admin.diff > > > The startup script for activemq-admin lags behind in the OS X specific launch > capabilities compared to the activemq launch script. All that is really > necessary is to catch it up with the activemq-admin OS detection capabilities. > Will attach patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQCPP-561) Memory Leak in ActiveMQConsumerKernel while calling deliverAcks
Jeremy Leung created AMQCPP-561: --- Summary: Memory Leak in ActiveMQConsumerKernel while calling deliverAcks Key: AMQCPP-561 URL: https://issues.apache.org/jira/browse/AMQCPP-561 Project: ActiveMQ C++ Client Issue Type: Bug Components: Other C++ Clients Affects Versions: 3.8.3 Reporter: Jeremy Leung Assignee: Timothy Bish -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (AMQCPP-561) Memory Leak in ActiveMQConsumerKernel while calling deliverAcks
[ https://issues.apache.org/jira/browse/AMQCPP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeremy Leung closed AMQCPP-561. --- Resolution: Duplicate > Memory Leak in ActiveMQConsumerKernel while calling deliverAcks > --- > > Key: AMQCPP-561 > URL: https://issues.apache.org/jira/browse/AMQCPP-561 > Project: ActiveMQ C++ Client > Issue Type: Bug > Components: Other C++ Clients >Affects Versions: 3.8.3 >Reporter: Jeremy Leung >Assignee: Timothy Bish > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
[ https://issues.apache.org/jira/browse/AMQ-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296281#comment-14296281 ] Tim Bain commented on AMQ-5542: --- One option to work around this problem might be to have a job that periodically consumes all DLQ messages and re-sends them to the DLQ as a new message. That way the dead messages are always near the newest messages in KahaDB and it can delete the old files. You'll lose metadata about when the original message was sent/received/etc., but that may be better than what you have now. (And you could always wrap the original message, with all its metadata, in a wrapper message if you wanted to keep that info.) This should still get fixed and the improvement I submitted should still get implemented, but that workaround might get you by until the improvement gets implemented. > KahaDB data files containing acknowledgements are deleted during cleanup > > > Key: AMQ-5542 > URL: https://issues.apache.org/jira/browse/AMQ-5542 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.0, 5.10.1 >Reporter: Sergiy Barlabanov > Attachments: AMQ-5542.patch, AdjustedAMQ2832Test.patch > > > AMQ-2832 was not fixed cleanly. > The commit dd68c61e65f24b7dc498b36e34960a4bc46ded4b by Gary from 8.10.2010 > introduced a problem by deleting too many files. > Scenarios we are facing currently in production: > Data file #1 contains unconsumed messages sitting in a DLQ. So this file is > not a cleanup candidate. > The next file #2 contains acks of some messages from file #1. This file is > not a cleanup candidate (because of ackMessageFileMap logic). > The next file #3 contains acks of some messages from file #2. And this file > is deleted during the cleanup procedure. So on Broker restart all messages > from #2, whose acks were from the deleted file #3, are replayed! > The reason is gcCandidates variable, which is a copy of gcCandidateSet (see > MessageDatabase#checkpointUpdate at the end of the method - > org/apache/activemq/store/kahadb/MessageDatabase.java:1659 on 5.10.0 tag). So > when a candidate is deleted from gcCandidateSet > (org/apache/activemq/store/kahadb/MessageDatabase.java:1668 on 5.10.0 tag), > gcCandidates still contains that candidate and the comparison on > org/apache/activemq/store/kahadb/MessageDatabase.java:1666 works wrong! > I will try to adjust AMQ2832Test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
[ https://issues.apache.org/jira/browse/AMQ-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296330#comment-14296330 ] Arthur Naseef commented on AMQ-5542: DLQs are a common cause of this problem. My recommendation when using DLQs is *always* have a plan for handling them and consume them in a timely manner. Again, if the messages need to be stored for a period of time (like 2 days), the best approach is to get them out of ActiveMQ and put them in some type of message store. Another consideration of this use-case: keeping the messages for this period means some manual action is expected. ActiveMQ is not designed to give "random access" to messages, which would typically be needed for manual intervention, but instead to produce and consume as a queue. This use-case would be better served with a database in which individual messages could be referenced. Regardless, this is how ActiveMQ currently functions. Until something better is implemented, these data files must not be deleted until they are no longer used. > KahaDB data files containing acknowledgements are deleted during cleanup > > > Key: AMQ-5542 > URL: https://issues.apache.org/jira/browse/AMQ-5542 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.0, 5.10.1 >Reporter: Sergiy Barlabanov > Attachments: AMQ-5542.patch, AdjustedAMQ2832Test.patch > > > AMQ-2832 was not fixed cleanly. > The commit dd68c61e65f24b7dc498b36e34960a4bc46ded4b by Gary from 8.10.2010 > introduced a problem by deleting too many files. > Scenarios we are facing currently in production: > Data file #1 contains unconsumed messages sitting in a DLQ. So this file is > not a cleanup candidate. > The next file #2 contains acks of some messages from file #1. This file is > not a cleanup candidate (because of ackMessageFileMap logic). > The next file #3 contains acks of some messages from file #2. And this file > is deleted during the cleanup procedure. So on Broker restart all messages > from #2, whose acks were from the deleted file #3, are replayed! > The reason is gcCandidates variable, which is a copy of gcCandidateSet (see > MessageDatabase#checkpointUpdate at the end of the method - > org/apache/activemq/store/kahadb/MessageDatabase.java:1659 on 5.10.0 tag). So > when a candidate is deleted from gcCandidateSet > (org/apache/activemq/store/kahadb/MessageDatabase.java:1668 on 5.10.0 tag), > gcCandidates still contains that candidate and the comparison on > org/apache/activemq/store/kahadb/MessageDatabase.java:1666 works wrong! > I will try to adjust AMQ2832Test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
[ https://issues.apache.org/jira/browse/AMQ-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296173#comment-14296173 ] Sergiy Barlabanov commented on AMQ-5542: This is correct. This is what we have in production. We have some messages in DLQs. They stay there for max 2 days. After that a special job removes messages older than 2 days from the DLQs. Now we expect that ActiveMQ will always retain nearly all data files for the last two days because of those messages in the DLQs. So this would take quite a lot of space I think and we did not expect that when we set up the servers - may be we will have to get a larger SAN volume for that. Another consideration is that this is not only the space which will be eaten by KahaDB but also the time ActiveMQ needs to recover after the crash. ActiveMQ will need quite a lot of time to replay all the data files which are sitting there just because of several DLQ messages. And the periodic cleanup may take more time to check all the data files (and KahaDB cleanup is a single threaded storage blocking operation). > KahaDB data files containing acknowledgements are deleted during cleanup > > > Key: AMQ-5542 > URL: https://issues.apache.org/jira/browse/AMQ-5542 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.0, 5.10.1 >Reporter: Sergiy Barlabanov > Attachments: AMQ-5542.patch, AdjustedAMQ2832Test.patch > > > AMQ-2832 was not fixed cleanly. > The commit dd68c61e65f24b7dc498b36e34960a4bc46ded4b by Gary from 8.10.2010 > introduced a problem by deleting too many files. > Scenarios we are facing currently in production: > Data file #1 contains unconsumed messages sitting in a DLQ. So this file is > not a cleanup candidate. > The next file #2 contains acks of some messages from file #1. This file is > not a cleanup candidate (because of ackMessageFileMap logic). > The next file #3 contains acks of some messages from file #2. And this file > is deleted during the cleanup procedure. So on Broker restart all messages > from #2, whose acks were from the deleted file #3, are replayed! > The reason is gcCandidates variable, which is a copy of gcCandidateSet (see > MessageDatabase#checkpointUpdate at the end of the method - > org/apache/activemq/store/kahadb/MessageDatabase.java:1659 on 5.10.0 tag). So > when a candidate is deleted from gcCandidateSet > (org/apache/activemq/store/kahadb/MessageDatabase.java:1668 on 5.10.0 tag), > gcCandidates still contains that candidate and the comparison on > org/apache/activemq/store/kahadb/MessageDatabase.java:1666 works wrong! > I will try to adjust AMQ2832Test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] activemq-6 pull request: upgrade to jetty 8 to be consistent with ...
Github user asfgit closed the pull request at: https://github.com/apache/activemq-6/pull/83 --- 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. ---
[GitHub] activemq-6 pull request: fix race in test
Github user asfgit closed the pull request at: https://github.com/apache/activemq-6/pull/84 --- 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: [VOTE] Apache ActiveMQ 5.11.0
+0 Honnestly, I'm not really concerned by the stomp failing tests (and stomp ;)), but I understand that it can "impact" users. Regards JB Le 2015-01-28 18:26, Daniel Kulp a écrit : I’m more or less -1 until someone can more fully explain the issue with the failing tests. The “patch” changes the test, but my question really is whether the original test code is “correct” and is really exposing some flaw in the stomp code that the new patch is really just working around. Are users that are using stomp going to have to make the same changes that were done in the test in their environments? If so, that’s a bigger issue. Thanks! Dan On Jan 26, 2015, at 4:02 PM, Gary Tully wrote: Hi folks, I've just cut a second release candidate for the long-awaited 5.11.0 release. This release has more than 120 bug fixes and improvements. Could you review the artifacts and vote? Especially, it would be great if you could test the unix shell script and make sure there's no any regressions on the platform you're using. The list of resolved issues is here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951 You can get binary distributions here: https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/ Source archives are here: https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/ Maven2 repository is at: https://repository.apache.org/content/repositories/orgapacheactivemq-1014/ Source tag: https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=f6eb86ee31640427d0f953847f38fcf81a71f9e1 The vote will remain open for 72 hours. [ ] +1 Release the binary as Apache ActiveMQ 5.11.0 [ ] -1 Veto the release (provide specific comments) Here's my +1 Regards Gary
Re: [VOTE] Apache ActiveMQ 5.11.0
If it doesn't build reliably from src, then I wouldn't suggest we release it. -1 from me On Mon, Jan 26, 2015 at 4:02 PM, Gary Tully wrote: > Hi folks, > > I've just cut a second release candidate for the long-awaited 5.11.0 release. > This release has more than 120 bug fixes and improvements. > > Could you review the artifacts and vote? Especially, it would be great if > you could test the unix shell script and make sure there's no any regressions > on the platform you're using. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/ > > Maven2 repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=f6eb86ee31640427d0f953847f38fcf81a71f9e1 > > The vote will remain open for 72 hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.11.0 > [ ] -1 Veto the release (provide specific comments) > > Here's my +1 > > Regards > > Gary
[jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
[ https://issues.apache.org/jira/browse/AMQ-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295447#comment-14295447 ] Tim Bain commented on AMQ-5542: --- Consumers can be timely but unsuccessful, leading to messages going to the DLQ, where they can cause exactly this kind of behavior. So as ActiveMQ is currently implemented the expectation Art referenced (that consumers be timely) needs to be applied to the DLQ as well, which isn't how I'd expect to need to interact with a DLQ. I would assume that I could come in the next morning, see that there were messages in the DLQ that failed for some reason, and decide what to do about them. But even if we simply fix this bug by not deleting the KahaDB files that are still needed (potentially all of them), then the consequence of that is going to be potentially large KahaDB disk usage for just a few messages, which I think most developers/admins won't be expecting. The way I just described interacting with the DLQ does in fact use it as a message store, and I think that's a valid use case. I think that fixing this specific bug is better than not (high disk usage is better than invalid message redelivery, IMO), but I think another solution (which could be mKahaDB, or something else such as having a separate KahaDB for the DLQ) is still needed (in a separate JIRA enhancement). I submitted AMQ-5547 to capture that need. > KahaDB data files containing acknowledgements are deleted during cleanup > > > Key: AMQ-5542 > URL: https://issues.apache.org/jira/browse/AMQ-5542 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.0, 5.10.1 >Reporter: Sergiy Barlabanov > Attachments: AMQ-5542.patch, AdjustedAMQ2832Test.patch > > > AMQ-2832 was not fixed cleanly. > The commit dd68c61e65f24b7dc498b36e34960a4bc46ded4b by Gary from 8.10.2010 > introduced a problem by deleting too many files. > Scenarios we are facing currently in production: > Data file #1 contains unconsumed messages sitting in a DLQ. So this file is > not a cleanup candidate. > The next file #2 contains acks of some messages from file #1. This file is > not a cleanup candidate (because of ackMessageFileMap logic). > The next file #3 contains acks of some messages from file #2. And this file > is deleted during the cleanup procedure. So on Broker restart all messages > from #2, whose acks were from the deleted file #3, are replayed! > The reason is gcCandidates variable, which is a copy of gcCandidateSet (see > MessageDatabase#checkpointUpdate at the end of the method - > org/apache/activemq/store/kahadb/MessageDatabase.java:1659 on 5.10.0 tag). So > when a candidate is deleted from gcCandidateSet > (org/apache/activemq/store/kahadb/MessageDatabase.java:1668 on 5.10.0 tag), > gcCandidates still contains that candidate and the comparison on > org/apache/activemq/store/kahadb/MessageDatabase.java:1666 works wrong! > I will try to adjust AMQ2832Test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5547) Provide a means to compact sparsely-populated KahaDB data files
Tim Bain created AMQ-5547: - Summary: Provide a means to compact sparsely-populated KahaDB data files Key: AMQ-5547 URL: https://issues.apache.org/jira/browse/AMQ-5547 Project: ActiveMQ Issue Type: Improvement Components: Message Store Reporter: Tim Bain AMQ-5542 describes a bug in our handling of KahaDB files where most but not all of the messages have been removed. In the comments, we describe a scenario where many files could be kept simply because of a single message in an older KahaDB file, because ack messages in file N+1 apply to messages in file N and so N+1 must be kept as long as N is. The problem exists because KahaDB data files can't be compacted, which is why mKahaDB (multi-KahaDB) was developed. We should either use mKahaDB, or we should find some other mechanism to ensure that unneeded data files aren't kept around simply because a single old message is still alive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Apache ActiveMQ 5.11.0
I’m more or less -1 until someone can more fully explain the issue with the failing tests. The “patch” changes the test, but my question really is whether the original test code is “correct” and is really exposing some flaw in the stomp code that the new patch is really just working around. Are users that are using stomp going to have to make the same changes that were done in the test in their environments? If so, that’s a bigger issue. Thanks! Dan > On Jan 26, 2015, at 4:02 PM, Gary Tully wrote: > > Hi folks, > > I've just cut a second release candidate for the long-awaited 5.11.0 release. > This release has more than 120 bug fixes and improvements. > > Could you review the artifacts and vote? Especially, it would be great if > you could test the unix shell script and make sure there's no any regressions > on the platform you're using. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/ > > Maven2 repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=f6eb86ee31640427d0f953847f38fcf81a71f9e1 > > The vote will remain open for 72 hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.11.0 > [ ] -1 Veto the release (provide specific comments) > > Here's my +1 > > Regards > > Gary -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
[ https://issues.apache.org/jira/browse/AMQ-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295399#comment-14295399 ] Arthur Naseef commented on AMQ-5542: To Tim's point -- if there is *any* content in the data file that means it is needed, then the file must not be removed. That problem exists even for messages - one, small message can hold an entire data file. Therefore, if there is an acknowledgement in the data file that still needs to be processed, the data file must not be removed. As Gary mentioned, multi-kahadb can be used to better prevent the scenario of large holes in data files. Keep in mind - it's in the JMS specification that consumers are expected to be "timely" (I forget the exact wording). ActiveMQ (and other JMS solutions) are not "message stores" - using them as such leads to many issues. If messages need to be stored for a length of time, I generally recommend adding a store to the architecture and moving those messages out of ActiveMQ and into the store as-needed. With that said, a solution to the compaction problem would be quite welcome. > KahaDB data files containing acknowledgements are deleted during cleanup > > > Key: AMQ-5542 > URL: https://issues.apache.org/jira/browse/AMQ-5542 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.0, 5.10.1 >Reporter: Sergiy Barlabanov > Attachments: AMQ-5542.patch, AdjustedAMQ2832Test.patch > > > AMQ-2832 was not fixed cleanly. > The commit dd68c61e65f24b7dc498b36e34960a4bc46ded4b by Gary from 8.10.2010 > introduced a problem by deleting too many files. > Scenarios we are facing currently in production: > Data file #1 contains unconsumed messages sitting in a DLQ. So this file is > not a cleanup candidate. > The next file #2 contains acks of some messages from file #1. This file is > not a cleanup candidate (because of ackMessageFileMap logic). > The next file #3 contains acks of some messages from file #2. And this file > is deleted during the cleanup procedure. So on Broker restart all messages > from #2, whose acks were from the deleted file #3, are replayed! > The reason is gcCandidates variable, which is a copy of gcCandidateSet (see > MessageDatabase#checkpointUpdate at the end of the method - > org/apache/activemq/store/kahadb/MessageDatabase.java:1659 on 5.10.0 tag). So > when a candidate is deleted from gcCandidateSet > (org/apache/activemq/store/kahadb/MessageDatabase.java:1668 on 5.10.0 tag), > gcCandidates still contains that candidate and the comparison on > org/apache/activemq/store/kahadb/MessageDatabase.java:1666 works wrong! > I will try to adjust AMQ2832Test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (AMQ-5546) selectorAware subscription cache replication
Pankaj Takawale created AMQ-5546: Summary: selectorAware subscription cache replication Key: AMQ-5546 URL: https://issues.apache.org/jira/browse/AMQ-5546 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.10.0 Environment: ActiveMQ 5.10.0 Replica Leveldb Cluster Reporter: Pankaj Takawale AMQ Replica LevelDB cluster does not replicate VirtualTopic Subscriber's selector expression. So on consumer disconnect followed by failover, new master does not have consumer's selector expression. It causes consumer to miss messages published during its offline duration. Steps to reproduce: 1. consumer subscribes (JMSSelector filter) 2. producer publishes 3. consumer consumes 4. consumer disconnects (offline) 5. Activemq *failover* occurs (new master gets elected) 6. producer publishes 7. consumer reconnects ( missed messages during offline period) I poked around SelectorAware cache code. It persists selector cache to local filesystem, that never gets replicated to slave nodes. Possible solution is to persists subscription info to leveldb, so that it gets replicated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (AMQ-5542) KahaDB data files containing acknowledgements are deleted during cleanup
[ https://issues.apache.org/jira/browse/AMQ-5542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295309#comment-14295309 ] Gary Tully commented on AMQ-5542: - mKahaDB is the current answer to the need for compaction/rewrite problem. that is why it emerged. Partition based on the average length of time a message spends in a queue. > KahaDB data files containing acknowledgements are deleted during cleanup > > > Key: AMQ-5542 > URL: https://issues.apache.org/jira/browse/AMQ-5542 > Project: ActiveMQ > Issue Type: Bug > Components: Message Store >Affects Versions: 5.10.0, 5.10.1 >Reporter: Sergiy Barlabanov > Attachments: AMQ-5542.patch, AdjustedAMQ2832Test.patch > > > AMQ-2832 was not fixed cleanly. > The commit dd68c61e65f24b7dc498b36e34960a4bc46ded4b by Gary from 8.10.2010 > introduced a problem by deleting too many files. > Scenarios we are facing currently in production: > Data file #1 contains unconsumed messages sitting in a DLQ. So this file is > not a cleanup candidate. > The next file #2 contains acks of some messages from file #1. This file is > not a cleanup candidate (because of ackMessageFileMap logic). > The next file #3 contains acks of some messages from file #2. And this file > is deleted during the cleanup procedure. So on Broker restart all messages > from #2, whose acks were from the deleted file #3, are replayed! > The reason is gcCandidates variable, which is a copy of gcCandidateSet (see > MessageDatabase#checkpointUpdate at the end of the method - > org/apache/activemq/store/kahadb/MessageDatabase.java:1659 on 5.10.0 tag). So > when a candidate is deleted from gcCandidateSet > (org/apache/activemq/store/kahadb/MessageDatabase.java:1668 on 5.10.0 tag), > gcCandidates still contains that candidate and the comparison on > org/apache/activemq/store/kahadb/MessageDatabase.java:1666 works wrong! > I will try to adjust AMQ2832Test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (AMQ-5545) Message order is not preserved across multiple consumers
[ https://issues.apache.org/jira/browse/AMQ-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinav Sarkari reopened AMQ-5545: -- I am reopening the issue. The bug/defect in Active MQ is the fact that message order is not preserved across multiple concurrent consumers. Message group merely provides a way to route/group certain messages to a single consumer. But doesn't support concurrent consumers consuming messages that have same group id. > Message order is not preserved across multiple consumers > > > Key: AMQ-5545 > URL: https://issues.apache.org/jira/browse/AMQ-5545 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.4.0 > Environment: The issue is seen on both Linux and Windows. >Reporter: Abhinav Sarkari > > There are multiple producers sending messages to a queue. There are multiple > consumers on this queue. > I want the consumers to pick messages in the same order as they have been > send by the producers. > The problem with using message group > (http://activemq.apache.org/message-groups.html) is that only one consumer > can consume these messages at a time. I want all the consumers on the queue > to be actively picking the messages. > In other words, is it possible to have multiple concurrent consumers being > part of the message group? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] activemq-6 pull request: fix race in test
GitHub user jbertram opened a pull request: https://github.com/apache/activemq-6/pull/84 fix race in test You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-6 master_work Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-6/pull/84.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 #84 commit d895988faf267aa39fe5b37312bd2cbdaa8168f3 Author: jbertram Date: 2015-01-27T19:29:05Z fix race in test --- 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. ---
[jira] [Closed] (AMQ-5545) Message order is not preserved across multiple consumers
[ https://issues.apache.org/jira/browse/AMQ-5545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-5545. - Resolution: Invalid Questions should be sent to the users mailing list. If a bug is confirmed then open a Jira, you probably won't get questions answered in a Jira. > Message order is not preserved across multiple consumers > > > Key: AMQ-5545 > URL: https://issues.apache.org/jira/browse/AMQ-5545 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.4.0 > Environment: The issue is seen on both Linux and Windows. >Reporter: Abhinav Sarkari > > There are multiple producers sending messages to a queue. There are multiple > consumers on this queue. > I want the consumers to pick messages in the same order as they have been > send by the producers. > The problem with using message group > (http://activemq.apache.org/message-groups.html) is that only one consumer > can consume these messages at a time. I want all the consumers on the queue > to be actively picking the messages. > In other words, is it possible to have multiple concurrent consumers being > part of the message group? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Apache ActiveMQ 5.11.0
+1 On Mon, Jan 26, 2015 at 4:02 PM, Gary Tully wrote: > Hi folks, > > I've just cut a second release candidate for the long-awaited 5.11.0 release. > This release has more than 120 bug fixes and improvements. > > Could you review the artifacts and vote? Especially, it would be great if > you could test the unix shell script and make sure there's no any regressions > on the platform you're using. > > The list of resolved issues is here: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951 > > You can get binary distributions here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/ > > Source archives are here: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/ > > Maven2 repository is at: > https://repository.apache.org/content/repositories/orgapacheactivemq-1014/ > > Source tag: > https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=f6eb86ee31640427d0f953847f38fcf81a71f9e1 > > The vote will remain open for 72 hours. > > [ ] +1 Release the binary as Apache ActiveMQ 5.11.0 > [ ] -1 Veto the release (provide specific comments) > > Here's my +1 > > Regards > > Gary -- Hiram Chirino Engineering | Red Hat, Inc. hchir...@redhat.com | fusesource.com | redhat.com skype: hiramchirino | twitter: @hiramchirino
[jira] [Created] (AMQ-5545) Message order is not preserved across multiple consumers
Abhinav Sarkari created AMQ-5545: Summary: Message order is not preserved across multiple consumers Key: AMQ-5545 URL: https://issues.apache.org/jira/browse/AMQ-5545 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.4.0 Environment: The issue is seen on both Linux and Windows. Reporter: Abhinav Sarkari There are multiple producers sending messages to a queue. There are multiple consumers on this queue. I want the consumers to pick messages in the same order as they have been send by the producers. The problem with using message group (http://activemq.apache.org/message-groups.html) is that only one consumer can consume these messages at a time. I want all the consumers on the queue to be actively picking the messages. In other words, is it possible to have multiple concurrent consumers being part of the message group? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Apache ActiveMQ 5.11.0
+1 (non-binding) I gave a kick of the tyres to the broker binary, built the source release and successfully ran a 'quick' subset of the tests (Client, Broker, AMQP, MQTT, LevelDB, Stomp with the below patch). I'd expect most users to grab binaries than build the source or run the tests. and as there has been a general commitment to do more frequent point releases the test fix can likely be incorporated into the next release before many will even try the 5.11.x series, so I'd agree the change shouldnt block the release (but should obviously be incorported if anything else did). Robbie On 27 January 2015 at 16:57, Gary Tully wrote: > I found one regression in stomp - fixed via > https://git1-us-west.apache.org/repos/asf?p=activemq.git;a=commit;h=1e5d2127 > which shows the config workaround. I think the use case is tenuous at > best so I don't think it should block the release. > > On 26 January 2015 at 21:02, Gary Tully wrote: >> Hi folks, >> >> I've just cut a second release candidate for the long-awaited 5.11.0 release. >> This release has more than 120 bug fixes and improvements. >> >> Could you review the artifacts and vote? Especially, it would be great if >> you could test the unix shell script and make sure there's no any regressions >> on the platform you're using. >> >> The list of resolved issues is here: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311210&version=12324951 >> >> You can get binary distributions here: >> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/apache-activemq/5.11.0/ >> >> Source archives are here: >> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/org/apache/activemq/activemq-parent/5.11.0/ >> >> Maven2 repository is at: >> https://repository.apache.org/content/repositories/orgapacheactivemq-1014/ >> >> Source tag: >> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=tag;h=f6eb86ee31640427d0f953847f38fcf81a71f9e1 >> >> The vote will remain open for 72 hours. >> >> [ ] +1 Release the binary as Apache ActiveMQ 5.11.0 >> [ ] -1 Veto the release (provide specific comments) >> >> Here's my +1 >> >> Regards >> >> Gary
[jira] [Commented] (AMQ-5537) Network Connector Throughput
[
https://issues.apache.org/jira/browse/AMQ-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294913#comment-14294913
]
Ehud Eshet commented on AMQ-5537:
-
I hope I was not too rude by specifying Fix Version as 5.11.
Where is the place or the mechanism to discuss such enhancement requests?
> Network Connector Throughput
>
>
> Key: AMQ-5537
> URL: https://issues.apache.org/jira/browse/AMQ-5537
> Project: ActiveMQ
> Issue Type: Improvement
> Components: Connector
>Affects Versions: 5.x
> Environment: Network of Brokers. Platform agnostic. Local Broker has
> a networkConnector defined to forward all messages to a remote broker.
>Reporter: Ehud Eshet
>
> *Requirement*
> 1. Allow network connector to use transactions when forwarding persistent
> messages.
> 2. Provide the following new network connector properties:
> maxMessagesPerTransaction - when specified and great than 1, use transactions.
> maxTransactionLatencyMillis - commit immediately when time passed since last
> commit is more than specified.
> Let's say both parameters are set as 1000.
> Network connector should commit after every 1000 messages or when more than
> 1000ms passed since last commit (the sooner).
> *Background*
> Persistent messages throughput is significantly slower.
> When using transactions and committing every 1000 messages, throughput on
> local broker with levelDB is about 12,000 messages of 1KB per second.
> Network connector does not use transactions. Thus, its throughput is limited
> to few hundreds messages per second.
> When imitating network connector functionality (receive from local broker and
> send to remote broker) using transactions on both sessions, I managed to have
> a sustained throughput of 10,000 messages/sec stored on local broker plus up
> to 11,000 messages/s forwarded to remote broker (forwarding throughput must
> be higher to allow catch up after reconnect).
> *Sample code*
> {code:title=TransactionalStoreAndForward.java|borderStyle=solid}
> import java.util.Date;
> import javax.jms.*;
> import javax.jms.Connection;
> import javax.jms.Message;
> import org.apache.activemq.*;
> import org.apache.activemq.broker.*;
> public class TransactionalStoreAndForward implements Runnable
> {
> private final String m_queueName;
> private final ActiveMQConnectionFactory m_fromAMQF, m_toAMQF;
>
> private Connection m_fromConn = null, m_toConn = null;
> private Session m_fromSess = null, m_toSess = null;
> private MessageConsumer m_msgConsumer = null;
> private MessageProducer m_msgProducer = null;
>
> private boolean m_cont = true;
>
> public static final int MAX_MESSAGES_PER_TRANSACTION = 500;
> public static final long MAX_TRANSACTION_LATENCY_MILLIS = 5000L;
>
> public TransactionalStoreAndForward(String fromUri, String toUri,
> String queueName)
> {
> m_fromAMQF = new ActiveMQConnectionFactory(fromUri);
> m_toAMQF = new ActiveMQConnectionFactory(toUri);
> m_queueName = queueName;
> }
>
> @Override
> public void run()
> {
> while (m_cont)
> {
> connect();
> process();
> }
> }
>
> private void process()
> {
> long txMessages = 0, totalMessages = 0, lastPrintMessages = 0;
> long startTime = 0L;
> long lastTxTime = startTime, lastPrintTime = startTime;
>
> Message msg = null;
>
> try {
> while (m_cont)
> {
> while ((msg =
> m_msgConsumer.receive(MAX_TRANSACTION_LATENCY_MILLIS)) != null)
> {
> if (startTime == 0) {
> startTime =
> System.currentTimeMillis();
> lastTxTime = startTime;
> lastPrintTime = startTime;
> }
>
> m_msgProducer.send(msg);
> txMessages++;
> totalMessages++;
>
> if (txMessages ==
> MAX_MESSAGES_PER_TRANSACTION ||
>
> System.currentTimeMillis() - lastTxTime > MAX_TRANSACTION_LATENCY_MILLIS)
> {
> m_toSess.commit();
>
