Export to GitHub

stomper - issue #9

Sender.py consumes the messages if there is no subscriber to receive them.


Posted on Jun 1, 2009 by Grumpy Horse

What steps will reproduce the problem? 1.Use sender.py and try sending messages. 2. Send Message1,Message2,Message3 3. And then try running the subscriber and see what messages does it receive?

What is the expected output? What do you see instead? We see the receiver receives messages Message2 and Message3,Message1 is consumed by the sender itself.It shows on the console that it received the messsage and prints the message accordingly.

What version of the product are you using? On what operating system?

Stomper "stomper-0[1].2.2-py2.4.egg" and opeating system is windows 2000.

Please provide any additional information below. I tried using the "activemq.noLocal" but it doesnt do the difference.

Please see the below console output of the sender.py.. It sends the message to the queue and then receives it back immediately. If we have some online subscribers then sender will not receive the message back.

E:\Python Programs\ActiveMQWithPython\Priority\MessagePriority> python TestPriorityQueueSender.py 2009-06-01 16:33:47,125 sender INFO Connected: session ID:2670-1243850573 893-4:49. Begining say hello. 2009-06-01 16:33:47,125 sender INFO Saying hello (1). 2009-06-01 16:33:47,125 sender INFO SENDER - received: The scenario is being ins erted in the database with priority 0

Comment #1

Posted on Jun 1, 2009 by Grumpy Horse

I am using ActiveMQ 5

Comment #2

Posted on Jun 9, 2009 by Helpful Camel

Hello,

I've just noticed this now, I'll have a look and see if I can repeat.

Oisin

Comment #3

Posted on Aug 8, 2010 by Helpful Camel

I'm getting ready to update for python3 release and I have some more time for this project again.

Yes, I get the same results with MorbidQ as well. I've also finally gotten to the bottom of what is going wrong with this. The sender has not completely subscribed before the loopingCall kicks in. Therefore it does not get the first message. I wrap the loopingCall in a reactor.callLater and this fixes this issue. The send and receiver now get this first message.

This fix will go into the next release 0.2.3

Status: Fixed

Labels:
Type-Defect Priority-Medium