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

Reply via email to