[zeromq-dev] REP returns Operation cannot be accomplished in current state

Antonio Teixeira eagle.antonio at gmail.com
Fri Jul 8 11:59:41 CEST 2011


Hello List.

I have nailed down the problem , to a problem right in my code oopsy [?] ,
apparently my messaging processing ( and response) was been bypassed by a
verification in my code and since i was not making any send() command and
all this is wrapped inside a While true :
It was raising that problem above. :\

Sorry all you guys for all the problem and stay tuned for more questions.

Thank you all for your time
António Teixeira



2011/7/8 Antonio Teixeira <eagle.antonio at gmail.com>

>
> Yes .
> No ZMQ object is shared across any Process.
> Just Network Definitions IP:Port
>
>
>
> 2011/7/8 Martin Sustrik <sustrik at 250bpm.com>
>
>> Do you create a new context after forking? There should be one context per
>> process.
>>
>> Martin
>>
>>
>> On 07/07/2011 04:44 PM, Antonio Teixeira wrote:
>>
>>> Hello List & Martin.
>>>
>>> I have traced the problem , to the following :
>>>
>>> If my collector is running stand alone (by this i mean no Chroot neither
>>> Fork() ) everything goes well :) hurray :D.
>>>
>>> Now if i grab that same code and insert it inside my Chrooted + Daemon (
>>> Double Fork per unix Specs) ZMQ losses contact with the world. ( TCP/
>>> INPROC , returns nothing)
>>>
>>> This is not affecting ZMQ.Device , The Parent Process is actually
>>> running a copy of the devices server code.
>>>
>>> Instead of Thread I'm using MultiProcessing , but continuing , the
>>> Parent issues zmq.device and if i launch in a local terminal my
>>> Collector Script I'm able to read data messages coming from the
>>> ZMQ.QUEUE meaning this is not the parent problem.
>>>
>>> Now if i place my collector script inside my daemon it will not be able
>>> to see any messages.
>>> It doesn't even come out with an error.
>>>
>>> A similar situation reported here.
>>> http://travlr.github.com/**zmqirclog/101229.html#msg-202<http://travlr.github.com/zmqirclog/101229.html#msg-202>
>>>
>>> Will keep doing more testing
>>> António
>>>
>>>
>>> 2011/7/4 Martin Sustrik <sustrik at 250bpm.com <mailto:sustrik at 250bpm.com>>
>>>
>>>
>>>    On 07/04/2011 04:46 PM, Antonio Teixeira wrote:
>>>
>>>        I assume Dealer manages this for me , because in multiprocessing
>>>        unless
>>>        i have shared memory i will be unable to sync RECV AND SEND
>>>        across all
>>>        processes.
>>>
>>>        You can even see there is no call to SEND in the code i posted
>>>        above.
>>>
>>>
>>>    I don't know exactly what you are doing but I assume you want to use
>>>    some other pattern, not REQ/REP. Check zmq_socket(3) man page for
>>>    list of available patterns:
>>>
>>>    http://api.zeromq.org/2-1:zmq-**__socket<http://api.zeromq.org/2-1:zmq-__socket>
>>>    <http://api.zeromq.org/2-1:**zmq-socket<http://api.zeromq.org/2-1:zmq-socket>
>>> >
>>>
>>>    Martin
>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110708/828c3c45/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 324.gif
Type: image/gif
Size: 98 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110708/828c3c45/attachment.gif>


More information about the zeromq-dev mailing list