Re: Could you be kind to fix amq-895?
Thank you for your apply. Yes, i've seen the suggestion. But I don't know how to configure failover transport for amq connecting to websphere mq. The following is from our configuration file like: jmsBridgeConnectors jmsQueueConnector name=activemq2webspheremq outboundQueueConnectionFactory=#remoteFactory outboundQueueBridges outboundQueueBridge outboundQueueName=WIN.TEST localQueueName=bridge2mq/ /outboundQueueBridges /jmsQueueConnector /jmsBridgeConnectors ... bean id=remoteFactory class=com.ibm.mq.jms.MQQueueConnectionFactory property name=transportType value=1/ property name=hostName value=Test/ property name=port value=1414/ property name=queueManager value=CSQ/ property name=channel value=CO.TEST/ /bean Did you mean I replace hostname's value to failover string? Thank you. Gary Tully wrote: does the suggestion in the comments of using the failover transport not work for you? 2009/7/27 sharpor wizardisha...@gmail.com Dears, We are facing the problem with amq-895 and roadmap said it should be fixed in version 5.4 and current status is unsigned. We are working on a project to try to replace some commercial messaging tools with amq and I think this problem is very important for amq to compete with other commercial tools. Could you be kind enough to fix this bug? Or could you experts give us any clues or references to solve this? Thank you in advances. :) My original post is: http://www.nabble.com/How-can-I-connect-to-Websphere-MQ--to23774518.html#a23774518 -- View this message in context: http://www.nabble.com/Could-you-be-kind-to-fix-amq-895--tp24673246p24673246.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com. -- http://blog.garytully.com Open Source Integration http://fusesource.com -- View this message in context: http://www.nabble.com/Could-you-be-kind-to-fix-amq-895--tp24673246p24694669.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Commented: (AMQ-2331) Message is sent to wrong broker in network of brokers inspite of using the Message selector
[ https://issues.apache.org/activemq/browse/AMQ-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52988#action_52988 ] Pradeep G commented on AMQ-2331: Gary, The 5.3 snapshot worked. When is the 5.3 release likely to happen ? If this is going to take a while (more than 2-3) weeks, can you provide us with a patch that I can use ? Regards, Pradeep. Message is sent to wrong broker in network of brokers inspite of using the Message selector --- Key: AMQ-2331 URL: https://issues.apache.org/activemq/browse/AMQ-2331 Project: ActiveMQ Issue Type: Bug Components: Broker, Connector, Selector Affects Versions: 5.2.0 Environment: All Reporter: Pradeep G Priority: Blocker Fix For: 5.2.0 I have a network of brokers configured in Hub/Spoke topology. The Spokes connect to the Hub via duplex network connector. Am using only Queues, and there are same set of Queues on both the Hub and the Spokes. Each of the Queues on the Spokes have only one consumer, and the consumer subscribes to messages based on a selector. The selector field is the Spoke ID (a simple name). The Hub transmits messages meant for a spoke by setting the message selector in the message to the Spoke ID. The idea is to send specific messages to the respective Spoke. So all the messages are sure to have the message selector set to the specific Spoke ID. The issue am facing is as follows. Suppose I have two Spokes A and B, and connect to a Hub say H via duplex network connector. Most times this setup works fine, but some times the messages meant for A are sent to B and vice-versa. Here is what I found in the logs: 2009-07-24 15:48:21,054 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///127.0.0.1:53209]: Journalled message add for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032207, file = 1, size = 444, type = 1 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 1 removing: 0 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///172.17.0.58:2673]: Journalled message remove for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032651, file = 1, size = 285, type = 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 0 removing: 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. The message was meant for a consumer in the broker running on machine 172.17.0.59, whereas the message is being removed from 172.17.0.58 (line 4). Is there a workaround or patch ? Thanks, Pradeep -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2331) Message is sent to wrong broker in network of brokers inspite of using the Message selector
[ https://issues.apache.org/activemq/browse/AMQ-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52992#action_52992 ] Gary Tully commented on AMQ-2331: - I would hope to cut a first release candidate towards the end of next week but the process may take a little longer. There are still a bunch of issues that need to be resolved or deferred. To see the relevant patch checkout the subversion commits attached to the issue: https://issues.apache.org/activemq/browse/AMQ-2104?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel Message is sent to wrong broker in network of brokers inspite of using the Message selector --- Key: AMQ-2331 URL: https://issues.apache.org/activemq/browse/AMQ-2331 Project: ActiveMQ Issue Type: Bug Components: Broker, Connector, Selector Affects Versions: 5.2.0 Environment: All Reporter: Pradeep G Priority: Blocker Fix For: 5.3.0 I have a network of brokers configured in Hub/Spoke topology. The Spokes connect to the Hub via duplex network connector. Am using only Queues, and there are same set of Queues on both the Hub and the Spokes. Each of the Queues on the Spokes have only one consumer, and the consumer subscribes to messages based on a selector. The selector field is the Spoke ID (a simple name). The Hub transmits messages meant for a spoke by setting the message selector in the message to the Spoke ID. The idea is to send specific messages to the respective Spoke. So all the messages are sure to have the message selector set to the specific Spoke ID. The issue am facing is as follows. Suppose I have two Spokes A and B, and connect to a Hub say H via duplex network connector. Most times this setup works fine, but some times the messages meant for A are sent to B and vice-versa. Here is what I found in the logs: 2009-07-24 15:48:21,054 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///127.0.0.1:53209]: Journalled message add for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032207, file = 1, size = 444, type = 1 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 1 removing: 0 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///172.17.0.58:2673]: Journalled message remove for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032651, file = 1, size = 285, type = 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 0 removing: 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. The message was meant for a consumer in the broker running on machine 172.17.0.59, whereas the message is being removed from 172.17.0.58 (line 4). Is there a workaround or patch ? Thanks, Pradeep -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2331) Message is sent to wrong broker in network of brokers inspite of using the Message selector
[ https://issues.apache.org/activemq/browse/AMQ-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-2331: Fix Version/s: (was: 5.2.0) 5.3.0 Message is sent to wrong broker in network of brokers inspite of using the Message selector --- Key: AMQ-2331 URL: https://issues.apache.org/activemq/browse/AMQ-2331 Project: ActiveMQ Issue Type: Bug Components: Broker, Connector, Selector Affects Versions: 5.2.0 Environment: All Reporter: Pradeep G Priority: Blocker Fix For: 5.3.0 I have a network of brokers configured in Hub/Spoke topology. The Spokes connect to the Hub via duplex network connector. Am using only Queues, and there are same set of Queues on both the Hub and the Spokes. Each of the Queues on the Spokes have only one consumer, and the consumer subscribes to messages based on a selector. The selector field is the Spoke ID (a simple name). The Hub transmits messages meant for a spoke by setting the message selector in the message to the Spoke ID. The idea is to send specific messages to the respective Spoke. So all the messages are sure to have the message selector set to the specific Spoke ID. The issue am facing is as follows. Suppose I have two Spokes A and B, and connect to a Hub say H via duplex network connector. Most times this setup works fine, but some times the messages meant for A are sent to B and vice-versa. Here is what I found in the logs: 2009-07-24 15:48:21,054 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///127.0.0.1:53209]: Journalled message add for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032207, file = 1, size = 444, type = 1 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 1 removing: 0 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///172.17.0.58:2673]: Journalled message remove for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032651, file = 1, size = 285, type = 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 0 removing: 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. The message was meant for a consumer in the broker running on machine 172.17.0.59, whereas the message is being removed from 172.17.0.58 (line 4). Is there a workaround or patch ? Thanks, Pradeep -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2331) Message is sent to wrong broker in network of brokers inspite of using the Message selector
[ https://issues.apache.org/activemq/browse/AMQ-2331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-2331. - Resolution: Duplicate Assignee: Gary Tully Message is sent to wrong broker in network of brokers inspite of using the Message selector --- Key: AMQ-2331 URL: https://issues.apache.org/activemq/browse/AMQ-2331 Project: ActiveMQ Issue Type: Bug Components: Broker, Connector, Selector Affects Versions: 5.2.0 Environment: All Reporter: Pradeep G Assignee: Gary Tully Priority: Blocker Fix For: 5.3.0 I have a network of brokers configured in Hub/Spoke topology. The Spokes connect to the Hub via duplex network connector. Am using only Queues, and there are same set of Queues on both the Hub and the Spokes. Each of the Queues on the Spokes have only one consumer, and the consumer subscribes to messages based on a selector. The selector field is the Spoke ID (a simple name). The Hub transmits messages meant for a spoke by setting the message selector in the message to the Spoke ID. The idea is to send specific messages to the respective Spoke. So all the messages are sure to have the message selector set to the specific Spoke ID. The issue am facing is as follows. Suppose I have two Spokes A and B, and connect to a Hub say H via duplex network connector. Most times this setup works fine, but some times the messages meant for A are sent to B and vice-versa. Here is what I found in the logs: 2009-07-24 15:48:21,054 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///127.0.0.1:53209]: Journalled message add for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032207, file = 1, size = 444, type = 1 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 1 removing: 0 2009-07-24 15:48:21,057 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Transport: tcp:///172.17.0.58:2673]: Journalled message remove for: ID:pgopal-lt-53198-1248427143033-2:6:1:97:27, at: offset = 1032651, file = 1, size = 285, type = 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Doing batch update... adding: 0 removing: 1 2009-07-24 15:48:21,062 DEBUG [org.apache.activemq.store.amq.AMQMessageStore] [ActiveMQ Task]: Batch update done. The message was meant for a consumer in the broker running on machine 172.17.0.59, whereas the message is being removed from 172.17.0.58 (line 4). Is there a workaround or patch ? Thanks, Pradeep -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2330) Add MBean descriptions
[ https://issues.apache.org/activemq/browse/AMQ-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52994#action_52994 ] Rob Davies commented on AMQ-2330: - Could you add the patch ? Add MBean descriptions -- Key: AMQ-2330 URL: https://issues.apache.org/activemq/browse/AMQ-2330 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.2.0 Reporter: Kyle Anderson Priority: Minor Original Estimate: 3 hours Remaining Estimate: 3 hours JMX allows for method/field/parameter descriptions, but AMQ registers standard Mbeans. This makes JMX though jconsole fairly cumbersome, one has to constantly consult the javadoc to understand the attributes and parameters. A simple solution is described here: http://weblogs.java.net/blog/emcmanus/archive/2005/07/adding_informat.html Using that approach, I was able to simply annotations copying the existing javadoc to the *ViewMBean classes and replaced the handful of the mbean registration calls. Patch available. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQCPP-257) Segfault on session or connection cleanup
Segfault on session or connection cleanup
-
Key: AMQCPP-257
URL: https://issues.apache.org/activemq/browse/AMQCPP-257
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl, Openwire
Affects Versions: 3.0.1
Environment: Windows Visual Studio 2005
Reporter: Ben Watrous
Assignee: Timothy Bish
I recently moved up to ActiveMQ CPP 3.0 (and now 3.0.1) from 2.2 to take
advantage of the failover transport, and discovered a segfault during testing.
It may be related to my test procedure, but I have found a quick patch to
activemq/core/ActiveMQSession.cpp that seems to resolve the issue.
It appears that in some cases of connection loss, the connection-disposeOf()
call may throw. In which case the Session is left in an invalid state - the
producers or consumer that caused the exception is still in the list, but it
has already been destroyed. This leads to an invalid pointer access later on.
In the current test, the exception is thrown because the connection to the
broker has been dropped so disposeOf fails.
Test Procedure:
Open the attached example (modified version of the basic sample) in the Visual
Studio debugger.
Set a breakpoint at the producer-send( message ); line.
Run to breakpoint.
To simulate a broken connection, connect to broker via JMX console and execute
the JMX Stop operation on the Connector for the producer.
Continue the debugger.
( Note: I Purge the TEST.FOO queue between runs since messages may sometimes
be left in queue during this type of testing. )
Suggested Patch to ActiveMQSession.cpp:
153a154
try {
155a157,159
}
/* Absorb */
AMQ_CATCHALL_NOTHROW()
1042a1047
this-consumers.remove( id );
1045c1050
this-consumers.remove( id );
---
//this-consumers.remove( id );
1065a1071
this-producers.remove( id );
1068c1074
this-producers.remove( id );
---
//this-producers.remove( id );
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQCPP-257) Segfault on session or connection cleanup
[
https://issues.apache.org/activemq/browse/AMQCPP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Watrous updated AMQCPP-257:
---
Attachment: main.cpp
Attached modified example
Segfault on session or connection cleanup
-
Key: AMQCPP-257
URL: https://issues.apache.org/activemq/browse/AMQCPP-257
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl, Openwire
Affects Versions: 3.0.1
Environment: Windows Visual Studio 2005
Reporter: Ben Watrous
Assignee: Timothy Bish
Attachments: main.cpp
I recently moved up to ActiveMQ CPP 3.0 (and now 3.0.1) from 2.2 to take
advantage of the failover transport, and discovered a segfault during
testing. It may be related to my test procedure, but I have found a quick
patch to activemq/core/ActiveMQSession.cpp that seems to resolve the issue.
It appears that in some cases of connection loss, the connection-disposeOf()
call may throw. In which case the Session is left in an invalid state - the
producers or consumer that caused the exception is still in the list, but it
has already been destroyed. This leads to an invalid pointer access later on.
In the current test, the exception is thrown because the connection to the
broker has been dropped so disposeOf fails.
Test Procedure:
Open the attached example (modified version of the basic sample) in the
Visual Studio debugger.
Set a breakpoint at the producer-send( message ); line.
Run to breakpoint.
To simulate a broken connection, connect to broker via JMX console and
execute the JMX Stop operation on the Connector for the producer.
Continue the debugger.
( Note: I Purge the TEST.FOO queue between runs since messages may
sometimes be left in queue during this type of testing. )
Suggested Patch to ActiveMQSession.cpp:
153a154
try {
155a157,159
}
/* Absorb */
AMQ_CATCHALL_NOTHROW()
1042a1047
this-consumers.remove( id );
1045c1050
this-consumers.remove( id );
---
//this-consumers.remove( id );
1065a1071
this-producers.remove( id );
1068c1074
this-producers.remove( id );
---
//this-producers.remove( id );
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQCPP-257) Segfault on session or connection cleanup
[
https://issues.apache.org/activemq/browse/AMQCPP-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Watrous updated AMQCPP-257:
---
Attachment: ActiveMQSession.cpp
Attached modified ActiveMQSession.cpp
Segfault on session or connection cleanup
-
Key: AMQCPP-257
URL: https://issues.apache.org/activemq/browse/AMQCPP-257
Project: ActiveMQ C++ Client
Issue Type: Bug
Components: CMS Impl, Openwire
Affects Versions: 3.0.1
Environment: Windows Visual Studio 2005
Reporter: Ben Watrous
Assignee: Timothy Bish
Attachments: ActiveMQSession.cpp, main.cpp
I recently moved up to ActiveMQ CPP 3.0 (and now 3.0.1) from 2.2 to take
advantage of the failover transport, and discovered a segfault during
testing. It may be related to my test procedure, but I have found a quick
patch to activemq/core/ActiveMQSession.cpp that seems to resolve the issue.
It appears that in some cases of connection loss, the connection-disposeOf()
call may throw. In which case the Session is left in an invalid state - the
producers or consumer that caused the exception is still in the list, but it
has already been destroyed. This leads to an invalid pointer access later on.
In the current test, the exception is thrown because the connection to the
broker has been dropped so disposeOf fails.
Test Procedure:
Open the attached example (modified version of the basic sample) in the
Visual Studio debugger.
Set a breakpoint at the producer-send( message ); line.
Run to breakpoint.
To simulate a broken connection, connect to broker via JMX console and
execute the JMX Stop operation on the Connector for the producer.
Continue the debugger.
( Note: I Purge the TEST.FOO queue between runs since messages may
sometimes be left in queue during this type of testing. )
Suggested Patch to ActiveMQSession.cpp:
153a154
try {
155a157,159
}
/* Absorb */
AMQ_CATCHALL_NOTHROW()
1042a1047
this-consumers.remove( id );
1045c1050
this-consumers.remove( id );
---
//this-consumers.remove( id );
1065a1071
this-producers.remove( id );
1068c1074
this-producers.remove( id );
---
//this-producers.remove( id );
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2333) Active MQ performance issues when there are more than a 1000 queue'd up messages
Active MQ performance issues when there are more than a 1000 queue'd up messages Key: AMQ-2333 URL: https://issues.apache.org/activemq/browse/AMQ-2333 Project: ActiveMQ Issue Type: Bug Components: Broker, JMS client Affects Versions: 5.2.0 Reporter: Marcus Malcom Over the past couple of days some of our queues get rather full because of downstream problems. The messages start numbering in the 1000's. When that happens ActiveMQ slows way down. I believe is slows down because we are trying to produce a message to the overloaded queue and it's taking a long time (minutes instead of seconds). Once the overloaded queue is emptied the problems go away. Our system pretty much has all the defaults. Note: this was not a problem before upgrading to 5.2.0 Any ideas on what should be done? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (AMQ-2016) Message grouping not honored when consumers started with existing messages
[
https://issues.apache.org/activemq/browse/AMQ-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=52998#action_52998
]
Rich commented on AMQ-2016:
---
Any luck getting a fix for version 5.2?
Message grouping not honored when consumers started with existing messages
--
Key: AMQ-2016
URL: https://issues.apache.org/activemq/browse/AMQ-2016
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.1.0, 5.2.0
Environment: JBOSS 4.2.2, AMQ 5.2.0 RA, JDK 1.5, Windows
Reporter: Hari Iyer
Assignee: Dejan Bosanac
Priority: Blocker
Fix For: 5.3.0
Attachments: MessageGroupDelayedTest.java, MessageGroupTest.java
Messages are processed FIFO when messages with different groups are sent to a
queue and then the consumers are started.
If the messages are sent after the consumers are started, then message
grouping works as expected.
Two JUnit tests are attached.
1. MessageGroupTest.java starts up 3 consumers and then sends 30 messages
evenly distributed across 3 groups A, B, and C.
Each consumer then gets assigned a group and the ordering is as expected
based on the different sleep intervals defined as seen in the log below
{quote}
2008-11-26 15:06:09,841 INFO [main] [com.test.MessageGroupTest] 30 messages
sent to group A/B/C
2008-11-26 15:06:09,841 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 9
2008-11-26 15:06:09,841 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 9
2008-11-26 15:06:09,841 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 9
2008-11-26 15:06:09,934 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 8
2008-11-26 15:06:10,044 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 7
2008-11-26 15:06:10,137 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 6
2008-11-26 15:06:10,247 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 5
2008-11-26 15:06:10,340 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 4
2008-11-26 15:06:10,450 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 3
2008-11-26 15:06:10,544 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 2
2008-11-26 15:06:10,653 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 1
2008-11-26 15:06:10,747 INFO [Thread-4] [com.test.MessageGroupTest] worker3
received msg C remaining 0
2008-11-26 15:06:10,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 8
2008-11-26 15:06:11,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 7
2008-11-26 15:06:12,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 6
2008-11-26 15:06:13,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 5
2008-11-26 15:06:14,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 8
2008-11-26 15:06:14,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 4
2008-11-26 15:06:15,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 3
2008-11-26 15:06:16,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 2
2008-11-26 15:06:17,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 1
2008-11-26 15:06:18,840 INFO [Thread-2] [com.test.MessageGroupTest] worker1
received msg B remaining 0
2008-11-26 15:06:19,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 7
2008-11-26 15:06:24,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 6
2008-11-26 15:06:29,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 5
2008-11-26 15:06:34,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 4
2008-11-26 15:06:39,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 3
2008-11-26 15:06:44,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 2
2008-11-26 15:06:49,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 1
2008-11-26 15:06:54,840 INFO [Thread-3] [com.test.MessageGroupTest] worker2
received msg A remaining 0
{quote}
2. MessageGroupDelayedTest.java sends 30 messages evenly distributed across 3
groups A, B, and C and then starts up 3 consumers.
All 30 messages are delivered in FIFO order to a single consumer as seen in
the log below
[jira] Created: (AMQ-2334) getJMSRedelivered() incorrectly returns false after a MasterSlave failover
getJMSRedelivered() incorrectly returns false after a MasterSlave failover -- Key: AMQ-2334 URL: https://issues.apache.org/activemq/browse/AMQ-2334 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Kyle Anderson Attachments: SanRedeliver.java Shared master/slave setup, described here http://activemq.apache.org/shared-file-system-master-slave.html Normally if one transacted consumer receives a message, then disconnects without committing, the message is marked as getJMSRedelivered() as true. If the broker fails and another takes over before the consumer disconnect, the message isn't marked as redelivered to the next consumer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2334) getJMSRedelivered() incorrectly returns false after a MasterSlave failover
[ https://issues.apache.org/activemq/browse/AMQ-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyle Anderson updated AMQ-2334: --- Attachment: SanRedeliver.java See attached unit test getJMSRedelivered() incorrectly returns false after a MasterSlave failover -- Key: AMQ-2334 URL: https://issues.apache.org/activemq/browse/AMQ-2334 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0 Reporter: Kyle Anderson Attachments: SanRedeliver.java Original Estimate: 3 hours Remaining Estimate: 3 hours Shared master/slave setup, described here http://activemq.apache.org/shared-file-system-master-slave.html Normally if one transacted consumer receives a message, then disconnects without committing, the message is marked as getJMSRedelivered() as true. If the broker fails and another takes over before the consumer disconnect, the message isn't marked as redelivered to the next consumer. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (AMQ-2335) Advisory messages for Connections distribute userNames and passwords
Advisory messages for Connections distribute userNames and passwords - Key: AMQ-2335 URL: https://issues.apache.org/activemq/browse/AMQ-2335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.2.0, 5.1.0, 5.0.0 Reporter: Rob Davies Assignee: Rob Davies Fix For: 5.3.0 Advisory messages for Connections distribute userNames and passwords -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2335) Advisory messages for Connections distribute userNames and passwords
[ https://issues.apache.org/activemq/browse/AMQ-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Davies resolved AMQ-2335. - Resolution: Fixed Fixed by SVN revision 798785 Advisory messages for Connections distribute userNames and passwords - Key: AMQ-2335 URL: https://issues.apache.org/activemq/browse/AMQ-2335 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.0.0, 5.1.0, 5.2.0 Reporter: Rob Davies Assignee: Rob Davies Fix For: 5.3.0 Advisory messages for Connections distribute userNames and passwords -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
