[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