[zeromq-dev] need advice to debug an alternative to CURVE in a multithread test

[Laurent Alebarde]

Good news Pieter, finally, CURVE works even when I penalise the 
handcheck, whatever implementation I use (multithread or sub-processes, 
shared context or not). Here is the report of my experiments (the first 
two was already described in the previous messages):

 1. Client multithreading with one shared context and the control socket
    with an inproc transport : works
 2. Client multithreading with one shared context and the control socket
    with an inproc transport, when 2ms or 20 ms delay is introduced
    inside
    zmq::curve_(client)|(server)_t::(next_handshake)|(process_handshake)_command
    : works (warning : needs increase of time at msleep (20000);
 3. Client multithreading with one context per client thread and the
    control socket with a TCP transport (mandatory since inproc works
    only in the same context) <http://pastebin.com/iVum5aGx>: works with
    2ms delay, and even with 20 ms delay (but needs increase of time at
    msleep (5000); line 281)
 4. Clients as sub-process <http://pastebin.com/wCs2s18G> (fork): works
    with 20ms delay

WARNING: my only GO/NOGO criteria is the number of DTOR in both clients 
and server. It is a very weak criteria but enabled me to have an easy 
way to investigate. I may come back with a full test when I have time.

The problem was I stopped the threads or the sub-processes from main 
before the work was performed. Penalizing each step of the handcheck 
makes things far longer :-[ !

The positive point is that we have now a set of examples.

Cheers,


Laurent.


Le 29/10/2013 15:09, Laurent Alebarde a écrit :
> Hi Pieter,
>
> Could this be the source of my problems ?
>
> /One of the big architectural blunders I've done in ZeroMQ is its 
> threading model. Each individual object is managed exclusively by a 
> single thread. That works well for async objects handled by worker 
> threads, however, it becomes a trouble for objects managed by user 
> threads./ <http://www.freelists.org/post/nanomsg/nanomsg-01alpha-released>
>
>
> Or has it been fixed ? May I expect it would work if I fork the 
> clients instead of using threads ?
>
> Cheers,
>
>
> Laurent
>
>
> Le 28/10/2013 16:30, Laurent Alebarde a écrit :
>> Thanks anyway Pieter. I found a description 
>> <http://zeromq.org/whitepapers:architecture> of the internals of 
>> libzmq 2, but nothing about timeouts. Thought, when I run 
>> test_concurrency_curve.cpp <http://pastebin.com/3xUbWEPj> with 2 ms 
>> delays into :
>>
>>   * zmq::curve_client_t::next_handshake_command
>>   * zmq::curve_client_t::process_handshake_command
>>   * zmq::curve_server_t::next_handshake_command
>>   * zmq::curve_server_t::process_handshake_command
>>
>> it stops working correctly (1 ms works well). I have not investigated 
>> the causes (just used DTOR traces), but I think it is expected to 
>> work ? Otherwise, the library may fail to work properly in some 
>> exceptional cases (may be concurrent running of more proprietary big 
>> processes), or in my case more cpu consumming mechanisms would fail.
>>
>> What do you think of that ? Should it be fixed ?
>>
>>
>> Le 25/10/2013 17:29, Pieter Hintjens a écrit :
>>> Laurent, I'm sorry, I don't know the internals of how mechanisms
>>> handle timeouts.
>>>
>>> On Fri, Oct 25, 2013 at 5:25 PM, Laurent Alebarde<l.alebarde at free.fr>  wrote:
>>>> The problem exists even in a normal run. Investigating without a debugger is
>>>> very difficult.
>>>>
>>>> What are the "timeouts" available in libzmq internals I can play with ?
>>>>
>>>> I have one point to examine: in my trace, I have indented depending on the
>>>> client id, and some printf are not in the good columns. That may be a good
>>>> start I assume ?
>>>>
>>>>
>>>> Le 25/10/2013 17:17, Pieter Hintjens a écrit :
>>>>
>>>> On Fri, Oct 25, 2013 at 4:22 PM, Laurent Alebarde<l.alebarde at free.fr>
>>>> wrote:
>>>>
>>>> My question is:
>>>> Considering CURVE, Is there some time delay I should deactivate when some
>>>> threads are paused ?
>>>>
>>>> Are you still using a debugger? That is always going to make things
>>>> work bizarrely.
>>>>
>>>> You should use whatever timeout seems reasonable, and tune it if you
>>>> find problems with your first choice.
>>>>
>>>> -Pieter
>>>> _______________________________________________
>>>> 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
>>>>
>>
>>
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131030/bc1fe4c0/attachment.htm>