You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Aaron Mulder (JIRA)" <ji...@apache.org> on 2008/05/17 00:37:44 UTC

[jira] Updated: (AMQ-1687) Error with virtual topic with more than one consumer name

     [ https://issues.apache.org/activemq/browse/AMQ-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aaron Mulder updated AMQ-1687:
------------------------------

    Attachment: GenericConsumer.java

For what it's worth, I did not see this with the attached consumer test for a VirtualTopic.  It is sure inefficient, but whatever.  Maybe this will help narrow down where the problem might be.

> Error with virtual topic with more than one consumer name
> ---------------------------------------------------------
>
>                 Key: AMQ-1687
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1687
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.1.0
>         Environment: Activemq 5.1.0 (04/23/08). java 1.6.0_02.
>            Reporter: Kevin McLaughlin
>            Priority: Critical
>         Attachments: GenericConsumer.java, VirtualTopicPubSubTest.java
>
>
> Tried upgrading to 5.1 today.  Seems virtual topics are broken with more than one different consumer name/queue.  This is a show-stopper for us as we're using this feature fairly heavily in 4.1 (with some issues, but none like this).
> ERROR Service                        - Async error occurred: java.lang.ClassCastException: org.apache.activemq.broker.region.Topic cannot be cast to org.apache.activemq.broker.region.Queue
> java.lang.ClassCastException: org.apache.activemq.broker.region.Topic cannot be cast to org.apache.activemq.broker.region.Queue
>         at org.apache.activemq.broker.region.QueueSubscription.acknowledge(QueueSubscription.java:50)
>         at org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:224)
>         at org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:359)
>         at org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:470)
>         at org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:194)
>         at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
>         at org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:73)
>         at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:84)
>         at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:443)
>         at org.apache.activemq.command.MessageAck.visit(MessageAck.java:196)
>         at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:292)
>         at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:180)
>         at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:68)
>         at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:143)
>         at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:206)
>         at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84)
>         at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:196)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:183)
>         at java.lang.Thread.run(Thread.java:619)
> This can be reproduced by modifying the existing VirtualTopicPubSubTest as attached (have two different consumer names).  I could not get it to error with an internal broker.  The easiest way to reproduce is to start an external broker and then run the attached test.  It seems to be important that the broker start clean.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.