You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by kureckam <mk...@fractech.net> on 2012/10/20 06:36:05 UTC
5.7 doesn't consume on queue
I'm in the process of updating from 5.5.1 to 5.7.0 but have an issue. The app
being updated sends a message on one queue and listens on a different queue.
The message is successfully sent and received by a Spring based app running
in Tomcat and using ActiveMQ 5.5.1. The Tomcat app places the ack message in
the queue and I see that it is enqueued but isn't received by updated app.
If I run the 5.5.1 activemq.bat file it works. Do I need to change something
else that I'm not aware of?
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-7-doesn-t-consume-on-queue-tp4658025.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: 5.7 doesn't consume on queue
Posted by kureckam <mk...@fractech.net>.
Thanks for the validation. Will this be the case from now on? For example,
if one was 5.6 and the other 5.7 would that still be a problem or is it just
a problem between mixing 5.5.1 and earlier versions with 5.6 or later? The
reason we use a network of brokers is to allow communications between any
computer with our pxx software to a singly specified computer with our fxx
software without affecting the other broker. Is there some other way of
performing such an operation?
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-7-doesn-t-consume-on-queue-tp4658025p4658226.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: 5.7 doesn't consume on queue
Posted by Christian Posta <ch...@gmail.com>.
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
<ch...@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 <mk...@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
Re: 5.7 doesn't consume on queue
Posted by Christian Posta <ch...@gmail.com>.
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 <mk...@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
Re: 5.7 doesn't consume on queue
Posted by kureckam <mk...@fractech.net>.
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.
Re: 5.7 doesn't consume on queue
Posted by Christian Posta <ch...@gmail.com>.
So I see two broker configs in activemq.xml:
pBroker <----duplex bridge ---> fBroker
and I see one broker $fBroker in the jms.xml.
I see the spring beans for the message listener container, and how it's
listening on START and a JMSTemplate that will send to ACK. Is the
connection factory pointing to the $fBroker?
I'm not seeing how pBroker/fBroker on the server have anything to do with
$fBroker.
On Wed, Oct 24, 2012 at 12:05 PM, kureckam <mk...@fractech.net> wrote:
> activemq.xml
> <http://activemq.2283324.n4.nabble.com/file/n4658191/activemq.xml> is on
> server side which sends a message on the START queue to the remote broker
> defined by jms.xml
> <http://activemq.2283324.n4.nabble.com/file/n4658191/jms.xml> and
> listens
> for ACK message. The server using the activemq.xml file is run as a
> standalone ActiveMQ application while the client listening on the START
> queue uses spring and runs in Tomcat. The setReplyTo method is set with the
> queue name to listen on for ACK. As I stated before the client side uses
> 5.5.1. If I use 5.5.1 on server side it works but if I use 5.7.0 on the
> server it doesn’t. Thanks for the help.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/5-7-doesn-t-consume-on-queue-tp4658025p4658191.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
--
*Christian Posta*
http://www.christianposta.com/blog
Re: 5.7 doesn't consume on queue
Posted by kureckam <mk...@fractech.net>.
activemq.xml
<http://activemq.2283324.n4.nabble.com/file/n4658191/activemq.xml> is on
server side which sends a message on the START queue to the remote broker
defined by jms.xml
<http://activemq.2283324.n4.nabble.com/file/n4658191/jms.xml> and listens
for ACK message. The server using the activemq.xml file is run as a
standalone ActiveMQ application while the client listening on the START
queue uses spring and runs in Tomcat. The setReplyTo method is set with the
queue name to listen on for ACK. As I stated before the client side uses
5.5.1. If I use 5.5.1 on server side it works but if I use 5.7.0 on the
server it doesn’t. Thanks for the help.
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-7-doesn-t-consume-on-queue-tp4658025p4658191.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: 5.7 doesn't consume on queue
Posted by Christian Posta <ch...@gmail.com>.
if you give enough info to recreate on our side, i can help.
i need broker configs and any client side configs you have
On Mon, Oct 22, 2012 at 5:20 AM, kureckam <mk...@fractech.net> wrote:
> This is over a networked broker and according to JMX the ack queue does
> exist. I also tried using 5.6 and that too doesn't work. Without changing
> any code and using the same config file, 5.5.1 works but 5.6 and 5.7 do
> not.
> I didn't see any logs on the issue. I don't understand why it doesn't work.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/5-7-doesn-t-consume-on-queue-tp4658025p4658045.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
--
*Christian Posta*
http://www.christianposta.com/blog
Re: 5.7 doesn't consume on queue
Posted by kureckam <mk...@fractech.net>.
This is over a networked broker and according to JMX the ack queue does
exist. I also tried using 5.6 and that too doesn't work. Without changing
any code and using the same config file, 5.5.1 works but 5.6 and 5.7 do not.
I didn't see any logs on the issue. I don't understand why it doesn't work.
--
View this message in context: http://activemq.2283324.n4.nabble.com/5-7-doesn-t-consume-on-queue-tp4658025p4658045.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: 5.7 doesn't consume on queue
Posted by Torsten Mielke <to...@fusesource.com>.
On Oct 20, 2012, at 6:36 AM, kureckam wrote:
> I'm in the process of updating from 5.5.1 to 5.7.0 but have an issue. The app
> being updated sends a message on one queue and listens on a different queue.
> The message is successfully sent and received by a Spring based app running
> in Tomcat and using ActiveMQ 5.5.1. The Tomcat app places the ack message in
> the queue and I see that it is enqueued but isn't received by updated app.
> If I run the 5.5.1 activemq.bat file it works. Do I need to change something
> else that I'm not aware of?
I am not aware of any changes in this regards. Have you double checked in JMX (e.g. jconsole) that there is a consumer registered on the queue that the Tomcat app writes the ack message to?
Can you browse the ack message using jconsole?
Any additional logging in the brokers log file that would indicate a problem?
Cheers,
Torsten Mielke
torsten@fusesource.com
tmielke@blogspot.com