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 <[email protected]> > > Yes . > No ZMQ object is shared across any Process. > Just Network Definitions IP:Port > > > > 2011/7/8 Martin Sustrik <[email protected]> > >> 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 <[email protected] <mailto:[email protected]>> >>> >>> >>> 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 >>> >>> >>> >> > >
<<324.gif>>
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
