[zeromq-dev] Deadlock with ctx_term

[Alexander Kampmann]

No, sorry, I can not share the code. It is not a small example, but a
system test for my entire project.

So, in the debugger it looks like context close is waiting for the
reaper thread to remove the last socket, but the reaper thread already
terminated, without destroying all sockets. I'll try the ZMQ_LINGER
option.

Alex

On 11/06/2015 06:48 PM, Michel Pelletier wrote:
> On Fri, Nov 6, 2015 at 3:12 AM, Alexander Kampmann < 
> s9alkamp at stud.uni-saarland.de> wrote:
> 
>> hey,
>> 
> I am using ZeroMQ in Java with PUSH and PULL sockets.
>> 
>> Basically everything is working as excepted, however, sometimes
>> the call to close() on the context deadlocks (jzmq makes that a
>> term() call on the context). The deadlock occurs with jzmq and
>> jeromq, and it would be rather strange if two implementations
>> have the same bug, so I suspect that this might be an error on my
>> part.
>> 
> 
> By deadlock, do you mean hang?  Deadlock is usually specifically
> used to indicate two threads waiting for each other to release the
> same resource.
> 
> If it's hanging, have you investigated the ZMQ_LINGER option?  A
> true deadlock would likely be a more serious bug.  Can you share
> your test case?
> 
> -Michel
> 
> 
>> 
>> Do you have any advice on how to debug this? Or maybe some 
>> frequently-made-error which can cause this?
>> 
>> The deadlock does not happen always, but too often (= I have a
>> test case which deadlocks approximately every fifth execution).
>> As I said, the deadlock happens for both, jzmq and jeromq. When I
>> attach my debugger to jeromq, I can see that the reaper-thread
>> terminated, but the sockets list in the context still contains a
>> PUSH socket. destroy() has not been called on the socket.
>> 
>> I think that close() is called, because I am using a
>> try-with-resource when I create the socket. If it indeed has not
>> been called, this is a bug in the java-8-compiler. I tried to
>> confirm that close has been called, but if I set a breakpoint or
>> add a printout in the close() method, the deadlock would not
>> occur. It did reappear after I removed the breakpoint/printout.
>> 
>> Best regards, Alex
>> 
>> _______________________________________________ zeromq-dev
>> mailing list zeromq-dev at lists.zeromq.org 
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
> 
> 
> 
> _______________________________________________ zeromq-dev mailing
> list zeromq-dev at lists.zeromq.org 
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>