Issue created.
On Thu, Apr 26, 2012 at 10:45 AM, Martin Hurton <hurt...@gmail.com> wrote: > Thanks Gerhard, could you please create an issue in Jira? And please > attach those Lua programs too. Thanks. > > - mh > > On Wed, Apr 25, 2012 at 5:08 PM, Gerhard Lipp <gel...@googlemail.com> wrote: >> i figured out to boil down an example, which shows this bug. >> it consists of three files: >> 1) x.lua doing the XREP XREQ stuff, must be started once >> 2) rep.lua implementing a simple echo replier, must be started once >> 3) req.lua making the request to rep.lua through x.lua. must be >> started TWICE to produce the error. THIS PROCESS LOCKS. uncommenting >> the ev.WRITE is a bad workaround to this issue. >> >> ----------- >> -- x.lua: >> ------------ >> local zmq = require'zmq' >> local ev = require'ev' >> local c = zmq.init(1) >> local xreq = c:socket(zmq.XREQ) >> xreq:bind('tcp://127.0.0.1:13333') >> local xrep = c:socket(zmq.XREP) >> xrep:bind('tcp://127.0.0.1:13334') >> local forward_io = >> function(src,dst) >> return ev.IO.new( >> function(loop,io) >> while true do >> local events = src:getopt(zmq.EVENTS) >> if events == zmq.POLLIN or events == (zmq.POLLIN + >> zmq.POLLOUT) then >> local more >> repeat >> local data = src:recv() >> local more = src:getopt(zmq.RCVMORE) > 0 >> dst:send(data,more and zmq.SNDMORE or 0) >> until not more >> else >> break >> end >> end >> end, >> src:getopt(zmq.FD), >> ev.READ -- + ev.WRITE -- "fixes" the problem >> ) >> end >> local xrep_io = forward_io(xrep,xreq) >> local xreq_io = forward_io(xreq,xrep) >> xreq_io:start(ev.Loop.default) >> xrep_io:start(ev.Loop.default) >> ev.Loop.default:loop() >> >> --------- >> -- req.lua >> ---------- >> local zmq = require'zmq' >> local c = zmq.init(1) >> local req = c:socket(zmq.REQ) >> req:connect('tcp://127.0.0.1:13334') >> while true do >> local r = tostring(math.random(1,10000000)) >> req:send(r) >> local x = req:recv() >> print(x,r) >> assert(x==r) >> end >> >> --------- >> -- rep.lua >> ------------ >> local zmq = require'zmq' >> local c = zmq.init(1) >> local rep = c:socket(zmq.REP) >> rep:connect('tcp://127.0.0.1:13333') >> while true do >> local x = rep:recv() >> rep:send(x) >> end >> >> >> >> On Mon, Apr 23, 2012 at 2:53 PM, Gerhard Lipp <gel...@googlemail.com> wrote: >>> Hello, >>> >>> I can observe the same behavior as stated here >>> (http://lists.zeromq.org/pipermail/zeromq-dev/2011-November/014615.html). >>> What I observe is also a XREP/XREQ (ROUTER/DEALER) prob, where the >>> XREQ is waiting forever to receive a message (which has been >>> definitely sent). When I poll (timer based) the ZMQ_EVENTs, the XREQ >>> is readable as expected. I am using libev (select based) for doing IO >>> and I am aware of the edge-based trigger behaviour (I am >>> reading/forwarding messages until ZMQ_EVENTs does not include the >>> ZMQ_POLLIN bit any more). >>> >>> What is the status of this issue? >>> Unfortunately my setup is a bit complicated to share, but i would like >>> to help as much as possible. >>> >>> Regards, >>> Gerhard >>> >>> A libev workaround is to use both EV_READ and EV_WRITE bits, though >>> this adds a lot of unnecessary wake ups / callbacks etc. >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev