Yep, that's the case. There are incompatible changes around the DemandForwarding bridge and the expected behaviors: The subscriptions are created slightly differently. Among possibly other changes, this SVN revision is what changed that would cause the behavior specifically that you're seeing:
https://fisheye6.atlassian.com/changelog/activemq?cs=1205508 >From this JIRA: https://issues.apache.org/jira/browse/AMQ-3384?page=com.atlassian.jirafisheyeplugin:fisheye-issuepanel In this case, you'll have to pick on version or the other for both brokers. Any specific reason why you need a network of brokers for this use case? On Wed, Oct 24, 2012 at 2:56 PM, Christian Posta <christian.po...@gmail.com>wrote: > There seems to be an issue with the bridge getting established properly, > probably due to the broker version mix and match. Like Torsten alluded to > earlier, the subscription isn't set up properly on the client's $fBroker, > ie, it doesn't see the subscription to the ACK queue coming from the > server's broker (fBroker) > > ActiveMQ wire protocols are backward compatible between clients and > brokers, but I don't think the same is true between brokers in a network of > brokers. I will dig around a little more to see what the exact issue is... > > > On Wed, Oct 24, 2012 at 12:53 PM, kureckam <mkure...@fractech.net> wrote: > >> pBroker in this case isn't relative because it is used for >> intercommunication >> between server components. The server fBroker networking with the client >> fBroker is the issue. The network connector xx.xxx.x.xxx (i.e. >> 173.194.77.147) setting indicates the client fBroker IP to connect to. >> >> >> >> -- >> View this message in context: >> http://activemq.2283324.n4.nabble.com/5-7-doesn-t-consume-on-queue-tp4658025p4658195.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> > > > > -- > *Christian Posta* > http://www.christianposta.com/blog > twitter: @christianposta > > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
