[jira] Created: (AMQ-1006) RoundRobinDispatchPolicy divides uneven
RoundRobinDispatchPolicy divides uneven --- Key: AMQ-1006 URL: https://issues.apache.org/activemq/browse/AMQ-1006 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Holger Bruch Priority: Minor Attachments: RoundRobinDispatchPolicyDivide.patch In case that multiple consumers with different message selectors are registered for the same destination, messages are not evenly divided. To reproduce, register 2 consumers for prio 9, one for prio 4. Of 1000 messages with prio 9 both prio 9 consumers should receive 500. Actually, the first consumer gets 667 messages, the second 333. This is caused by the consumer shifting strategy in the RoundRobinDispatchPolicy which rotates consumers, even if they did not match. The attached file contains a testcase illustrating the behavior and a patch for RoundRobinDispatchPolicy, that shifts the first matching consumer instead of the first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-962) Messages are read from queue but not removed
[ https://issues.apache.org/activemq/browse/AMQ-962?page=comments#action_37139 ] Holger Bruch commented on AMQ-962: -- I encountered a similar problem when using the PooledConnectionFactory, which is currently intended for sending messages only. In my case, it was caused by a concurrency issue when the session is closed and messages are still processed by the consumer. The PooledSession does not halt the underlying session's executor, so that messages are still delivered when the session is about to close. These messages might in your case be read, but not acknowledged. Messages are read from queue but not removed Key: AMQ-962 URL: https://issues.apache.org/activemq/browse/AMQ-962 Project: ActiveMQ Issue Type: Bug Components: JMS client, Broker Affects Versions: 4.0.1 Environment: Java Virtual Machine: Java HotSpot(TM) Server VM version 1.5.0_06-b05JIT compiler: HotSpot Server Compiler Operating System: Windows XP 5.1 Architecture: x86 Number of processors: 1 Total physical memory: 1,048,048 kbytes Free physical memory: 107,240 kbytes Committed virtual memory: 374,048 kbytes Total swap space: 2,518,944 kbytes Free swap space: 721,416 kbytes Reporter: Randy Priority: Critical Fix For: 4.1 Using Spring, configured a VM message broker (non-persistant) and a message consumer that reads messages from queue. Messages are read from queue, but despite calling message.acknowledge(); messages remain on the queue (and consume memory). I turned off optimiseAcknowledge. May be related to bug# AMQ-716. amq:broker id=broker useJmx=true persistent=false amq:transportConnectors amq:transportConnector uri=tcp://localhost:0 / /amq:transportConnectors /amq:broker !-- a pooling based JMS provider -- bean id=jmsFactory class=org.apache.activemq.pool.PooledConnectionFactory property name=connectionFactory bean class=org.apache.activemq.ActiveMQConnectionFactory property name=brokerURL valuevm://localhost/value /property property name=optimizeAcknowledge valuefalse/value /property /bean /property /bean bean id=simpleJmsTemplate class=org.springframework.jms.core.JmsTemplate property name=connectionFactory ref local=jmsFactory / /property /bean -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-961) Problem with subscription passing with network of brokers in AMQ 4.0.2
[ https://issues.apache.org/activemq/browse/AMQ-961?page=all ] Holger Bruch updated AMQ-961: - Attachment: RestartDFBOnResume.diff Might relate to the problem I encountered in http://www.nabble.com/Failover-and-DemandForwardingBridge-tf2383410.html#a6642973. Apparently, the DemandForwardingBridge does not resume correctly after a network interruption. For me, the attached patch worked, but I'm not aware of any side effects, so please check. Problem with subscription passing with network of brokers in AMQ 4.0.2 -- Key: AMQ-961 URL: https://issues.apache.org/activemq/browse/AMQ-961 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Reporter: Kevin Yaussy Priority: Critical Attachments: RestartDFBOnResume.diff There's an occasional problem with subscription propagation when using a network of brokers. Test scenario uses ConsumerTool and PublisherTool in examples area of distribution. 1) Start broker A (has a network connection to broker B) 2) Start broker B (has a network connection to broker A) 3) start consumer C against broker A, on FOO 4) start publisher P against broker B, on FOO Messages do not flow to consumer C. In the broker B log, there's no indication it got any subscriptions from broker A. Again, this is occasional. I've taken a kill-3 on the brokers, both when this condition appears, and when everything is fine. There's an obvious difference in one of the threads that hopefully will bring light to the problem. I've not gone into the code yet to try and find the issue, but figured I would open this issue first. Stack trace of broker A when subscriptions did NOT pass, and message flow is broken: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x0030e160 nid=0x3f in Object.wait() [0x8 e2ff000..0x8e2ff8f0] at java.lang.Object.wait(Native Method) - waiting on 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at java.lang.Object.wait(Object.java:474) at edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch.await(CountDownLatch.java:179) - locked 0x9b2b00d0 (a edu.emory.mathcs.backport.java.util.concurrent.CountDownLatch) at org.apache.activemq.network.DemandForwardingBridgeSupport.waitStarted(DemandForwardingBridgeSupport .java:830) at org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBrid geSupport.java:329) at org.apache.activemq.network.DemandForwardingBridgeSupport$2.onCommand(DemandForwardingBridgeSupport .java:130) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.failover.FailoverTransport$1.onCommand(FailoverTransport.java:117) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:124) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) Stack trace of broker A when everything works correctly: ActiveMQ Transport: tcp://perfgc1a/170.137.15.169:5112 prio=10 tid=0x01955fc8 nid=0x3f runnable [0x8e2cf000..0x8e2cfaf0] at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:49) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:56) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:275) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-959) Wrong message removed from store when using composite destinations
Wrong message removed from store when using composite destinations --- Key: AMQ-959 URL: https://issues.apache.org/activemq/browse/AMQ-959 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2 Environment: AMQ4.0.2 using jdbc-persistence Reporter: Holger Bruch Attachments: CopyMessageId.diff When sending messages to composite destinations, for each simple destination a copy of the original message is created an sent. However, it's internal messageId is reused. As the messageId carries the brokerSequenceId, which is used as primary key in the jdbc message store, this is overwritten by the last send. All messages refer to the same store row so that the first acknowledge removes the content for all MessageReferences in memory. The attached patch creates a copy of the messageId when copying a message. Regards, Holger -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-879) Destination statistics message count is not decremented after message expired
Destination statistics message count is not decremented after message expired - Key: AMQ-879 URL: https://issues.apache.org/activemq/browse/AMQ-879 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Reporter: Holger Bruch Priority: Minor Attachments: StatisticsMessagesCountTest.java After consuming an expired message from a queue, the destination statistics messages count is not decremented. See also the included test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-880) Expired messages should trigger an advisory message
Expired messages should trigger an advisory message --- Key: AMQ-880 URL: https://issues.apache.org/activemq/browse/AMQ-880 Project: ActiveMQ Issue Type: New Feature Components: Broker Affects Versions: 4.0.1 Reporter: Holger Bruch http://www.activemq.org/site/advisory-message.html describes message based advisories. Support for expired messages advisory is currently not implemented. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
