[zeromq-dev] Weird zmq_receive behavior on blocking

[Sean McKay]

Please disregard the comment about using AppDomains still causing the issue
-- that was incorrect.  AppDomains do properly resolve it.

Sean

-----Original Message-----
From: Sean McKay [mailto:sean at on-track-solutions.com] 
Sent: Friday, July 03, 2009 10:23 PM
To: 'Pavol Malosek'; 'Martin Sustrik'
Cc: 'zeromq-dev at mail.imatix.com'
Subject: RE: [zeromq-dev] Weird zmq_receive behavior on blocking

Pavol,

Can you tell me if putting a separate api_thread_t instance in a different
.Net AppDomain is adequate?  Normally, I would think so since it is supposed
to provide an entirely different application execution context, but I have
tried this scenario and still run into the issue.

Thanks,
Sean

-----Original Message-----
From: Pavol Malosek [mailto:malosek at fastmq.com] 
Sent: Thursday, July 02, 2009 11:35 AM
To: Sean McKay; 'Martin Sustrik'
Cc: zeromq-dev at mail.imatix.com
Subject: Re: [zeromq-dev] Weird zmq_receive behavior on blocking

Hello Sean,

The problem you are seeing is caused by using single zmq api by the two
application threads.
The rule is to have zmq api in each application thread.
---
zmq::api_thread_t (3)

DESCRIPTION
The API thread is a proxy for an application thread to access 0MQ
functionality.
For each of your application threads that needs to use 0MQ you should create
an instance of the api_thread class.
---


            ThreadPool.QueueUserWorkItem(createManager);
            Thread.Sleep(2000);
            ThreadPool.QueueUserWorkItem(createRequestor);
            Thread.Sleep(1000);
            ThreadPool.QueueUserWorkItem(createWorker);

            Message msg = new Message();
            msg.Callback = WeGotIt;
            msg.CommandID = DateTime.Now.Ticks;
            msg.CommandName = "Create Project";
            msg.ID = 10;
            msg.SourceHostID = 0;
            msg.SystemType = 1;
            msg.TargetHostID = 1;
            _requestorQ.Send("Requestor:Sender",msg);
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  Message should be send from
requestor thread and not from here!

Moreower, would be better to start threads in order manager, worker and then
requester.

One issue which could possibly cause your initial problems has been solved
meanwhile (r1556).
Anyway, when _requestorQ.Send call was moved to requestor thread we could
get full message roundtrip in 100% tries.

Please let us know if it works for you.

malo


----- Original Message -----
From: "Sean McKay" <sean at on-track-solutions.com>
To: "'Martin Sustrik'" <sustrik at fastmq.com>
Cc: <zeromq-dev at mail.imatix.com>
Sent: Thursday, June 18, 2009 4:38 PM
Subject: Re: [zeromq-dev] Weird zmq_receive behavior on blocking


> This version only has the C# code so as to fit under the ML constraints...
>
> -----Original Message-----
> From: Sean McKay [mailto:sean at on-track-solutions.com]
> Sent: Tuesday, June 16, 2009 3:37 PM
> To: 'Martin Sustrik'
> Cc: 'zeromq-dev at mail.imatix.com'
> Subject: RE: [zeromq-dev] Weird zmq_receive behavior on blocking
>
> Hi Martin,
>
> I apologize for the long delay.  I am behind on a number of tasks, and
just
> got a chance to make a "small" subset of the code that reproduces the bug.
> I regret I don't have the time to make it even shorter.
>
> There is a slight difference between the possible bug I originally
reported
> and what this application shows -- it doesn't reveal itself until the last
> step in the round trip.  So it will go from Request to Manager to Worker
to
> Manager and stop there for some reason.  The original issue I reported
> stopped between the Worker sending to the Manager.
>
> To turn on the bug (the non-blocking _working_ version is currently used)
> switch:
> _zmqServer.Receive(out inMessage, out type, false);
>
> To
>
> _zmqServer.Receive(out inMessage, out type, true);
>
> Thanks,
>
> Sean
>