consumer close and stop not returning

[GoogleCodeExporter]

1. send messages to non-durable topic with asynchronous consumer
2. try and stop() the connection or close() the consumer/session/connection
3. process flow hangs

Should expect to see the methods returning cleanly and message flow
stopping. Instead, the method doesn't return (blocks)

Experienced this on linux with ActiveMQ 5.1 5.2 & 5.3, ActiveMQ-CPP-2.2.1
built pyactivemq from 0.1.0.

Original issue reported on code.google.com by will.van...@gmail.com on 28 Nov 2008 at 9:59

[GoogleCodeExporter]

Please attach a complete test case.

Original comment by fullung@gmail.com on 28 Nov 2008 at 10:01

[GoogleCodeExporter]

Original comment by fullung@gmail.com on 28 Nov 2008 at 10:01

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by fullung@gmail.com on 28 Nov 2008 at 10:01

[GoogleCodeExporter]

I'll create a test case soon (I'm using a wrapper so will have to unpack it).

It seems that the connection.close() and connection.send() are the culprits but 
only
as long as there are pending messages on the broker.

Original comment by will.van...@gmail.com on 28 Nov 2008 at 11:46

[GoogleCodeExporter]

test case attached.

It will never reach the "stopped" print statement. I'm not sure why.
Same happens if we try and close the connection.

Original comment by will.van...@gmail.com on 5 Dec 2008 at 1:42

Attachments:

• stop_error.py

[GoogleCodeExporter]

Okay I have reproduced this issue. Looks like it might be a deadlock involving 
AMQCPP 
or maybe the GIL.

Original comment by fullung@gmail.com on 3 Jan 2009 at 10:29

[GoogleCodeExporter]

Things go awry when messages are still being delivered to the message handler 
while 
the connection is stopped at the "same" time.

I think it would be a good idea to rewrite this code against the C++ API so 
that we 
can make sure that the problem isn't there. If we can't reproduce it, then we 
can 
think about whether the wrapper needs work.

Original comment by fullung@gmail.com on 3 Jan 2009 at 10:34

[GoogleCodeExporter]

Okay, I think this might be the same bug as issue #25. The main thread is 
calling 
stop from Python, which locks the GIL and then waits on a mutex for message 
listeners 
to complete. Meanwhile the code that calls the message listener has locked the 
mutex 
and is trying to lock the GIL.

Now to figure out how to fix it...

Original comment by fullung@gmail.com on 4 Jan 2009 at 9:55

[GoogleCodeExporter]

Useful documentation: http://docs.python.org/c-api/init.html

Original comment by fullung@gmail.com on 4 Jan 2009 at 9:59

[GoogleCodeExporter]

Here's a patch that seems to fix the problem. We just need to think about 
whether 
Stoppable::stop is the only function that needs to release the GIL.

Original comment by fullung@gmail.com on 4 Jan 2009 at 6:20

Attachments:

• stop_error.diff

[GoogleCodeExporter]

Patch isn't quite right yet...

Original comment by fullung@gmail.com on 4 Jan 2009 at 7:50

[GoogleCodeExporter]

OK. revisiting AMQ-CPP after a hiatus. Will see if I can figure out more.

Original comment by will.van...@gmail.com on 5 Mar 2009 at 11:18

[GoogleCodeExporter]

The most important thing to do is to show whether we can reproduce this problem 
without involving pyactivemq.

Original comment by fullung@gmail.com on 5 Mar 2009 at 11:40