[zeromq-dev] Python / Zmq / Gevent

[Antonio Teixeira]

So Everything works fine the the client doesn't use a device...
I maybe missing something but its only working this way ( The context is
been shared across greenlets.).

2012/4/20 Antonio Teixeira <eagle.antonio at gmail.com>

> After Digging a little further i was able to understand a little bit more :
>
> I can see the data leaving my client and going to the server ...
>
> *%.3e26cbc5-c68f-4fe5-8b16-ed7d3d93517c*
> ....e../..5..+..J..s..a..u..N..D..e..n..r..j..e..X..X..A..z..n..0..r..h..h..d..9../..c..2..u../..q..b..y..L..t..v..3..Z..l..w..5..+..9..Z..5..y..2..s..S..F..x..N..U..6..e..9..L..F..X..v..f..Q..c..F..J..M..j..z..D..W..g..u..n..5..M..s..I..e..B..8..y../..r..J..n..Y..x..D..v..f..f..V..Q..3..3..5..p..X..o..S..m..9..6..p..k..g..l..Z..T..0..H..n..n..P..9..2..5..r..9..m..X..F..p..C..F..E..H..k..x..I..v..c..D..n..I..e..7..H..f..b..a../..n..Z..9..j..i..S..r../..L..X..6..S..y..9..t..W..W..a..x..k..k..x..8..1..4..+..E..k.
>
> And the server response :
> *=%.3e26cbc5-c68f-4fe5-8b16-ed7d3d93517c*
> ....a..2..+..6..k..9..I..C..4..u..n..G..a..S..q..+..I..q..I..G..K..1..N..r..L..x..2..w..F..j..C..8..B..7..+..h../..9../..U..z..I..9..O..k..0..q..d..g..T..v..w..7..6..1..D..R..s..V..e..x..j..n..9..0..t..D..4..K..8..+../..o..U..U..B..e..6..z..x..7..K..l..j..T..X..N..C..i..3..X..i..e..K..P..T..n..4..e..h..Z..A..W..T..G..U..R..z..5..M..E..y..y..Y..t..X..7..9..X..3..2..a..O..Z..n..L..x..P..C..Z..V..3..X..6..3..L..E..Y..X..V..O..g..i..W..c..8..e..R..a..C..2..z..4..Z..W..R..1..8..H..C..3..2..d..y..C..D..O..C..v..b..J..3..e..7..y..e..c..W..1..x..X..Z..K..N..G..P..r..b..0..U..N..I..x..b..R..u..f..P..S..m..J..E..O..u..q..t..h..N..f..L..u..l..m..n..H..C..g..B..L..p..T..H..P..T..Q..P..d..M..n..W..M..F..C..5..9..9..c..s..k..0..K..u..s..B..w..N..O..n..l..d..2..p..9..n..0..u..D..r..H..q..1..z..e..a..q..M..V..h..e..w..w..7..d..y..u..2..v../..w..Z..8..B../..g..x..9..g..2..p..t..+..G..h..V..M..l..t../..V..Y..v..9../..a..W..8..Z..h..e..N..l..f..4..t..s..6..o..c..y..F..Z..X..6..i..d..v..G..y..M..G..J..9..6..K..5..x..M..O..f..G..f..w..=.
>
>
> I'm assuming that the bold part is the "envelope" , anyway this never
> reaches the device on the client ( that i'm currently printing all the
> messages that goes trough) so i can imagine that
> REQ > ROUTER >(Device)> DEALER > ROUTER >(Device)> DEALER > REP
>
> Is not working with gevent ?! the strange part is that it works for a
> couple of messages ( about 10 /20) than it stops I'm going to create one
> socket for every greenlet so instead of
> REQ > ROUTER >(Device)> DEALER > ROUTER >(Device)> DEALER > REP
> i will have
> REQ  > ROUTER >(Device)> DEALER > REP
> To see how that goes :\
>
> if any of you guys can give a hand i will be appreciated
>
> 2012/4/19 Antonio Teixeira <eagle.antonio at gmail.com>
>
>> Hello Paul
>>
>> A socket an IPC socket is been created per greenlet that connects to the
>> ipc socket.
>>
>> To be more precise
>>
>> 10 x REQ (ipc://IPC/SOCKET- Connect) and the next hop its a ROUTER that
>> bind on the ipc socket sitting on the "parent greenlet"
>>
>>
>>
>>
>>
>> 2012/4/19 Paul Colomiets <paul at colomiets.name>
>>
>>> Hi Antonio,
>>>
>>> On Thu, Apr 19, 2012 at 6:42 PM, Antonio Teixeira
>>> <eagle.antonio at gmail.com> wrote:
>>> > Hello Once Again :)
>>> >
>>> > I have deployed the following scenario :
>>> >
>>> > REQ (ipc://IPC/SOCKET- Connect - Using Multiple Threads/ Greenlets) ->
>>> (IPC
>>> > ROUTER - Bind ipc://IPC/SOCKET) -> (DEALER TCP - Connect:
>>> 127.0.0.1:2222)
>>> > -> (Router TCP Bind :127.0.0.1:2222) - (IPC DEALER - Bind
>>> ipc://IPC/SOCKET2)
>>> > -> REP ( Using Multiple Threads/ Greenlets Connect - ipc://IPC/SOCKET2)
>>> >
>>> > A Thread make the place of the device with a simple:
>>> >
>>> > data = recv()
>>> > send(data)
>>> >
>>> > All code based on this :
>>> > https://github.com/zeromq/pyzmq/blob/master/examples/gevent/reqrep.py
>>> >
>>> > On The REP Side 10 Greenlets
>>> > On The REQ Side 1 Greenlet
>>> >
>>> > 100 Tasks ( A simple print and return)
>>> >
>>> > Everything Works Well.
>>> >
>>> > The same as above
>>> >
>>> > On The REP Side 10 Greenlets
>>> > On The REQ Side 5 Greenlet
>>> >
>>> > It works well until ...
>>> > Did Not Receive A Response The Destination Server Is Unreachable.
>>> > Ok so Pieter and other at the mailing list pointed me that if the
>>> socket
>>> > disconnects we clear the socket.
>>> >
>>> > self.workerSocket.setsockopt(zmq.LINGER, 0)
>>> > self.workerSocket.close()
>>> >
>>> > And make a new one , well this still doesn't work.
>>> > The REP Side is still online and available since i can use another
>>> machine
>>> > with the "client software ( the REP Part) " and it works perfectly
>>> until the
>>> > same happens.
>>> >
>>> > So to "The Guide" we go.
>>> > Set Linger 0 to ensure everything is dropped , checked OK
>>> > Close the socket and started a new one , checked OK
>>> > Use identity in case stuff gets funky , so one UUID for each worker
>>> inside
>>> > the client set before we connect to the IPC , checked OK
>>> >
>>> > So after all this the problem remains but when I'm terminating the
>>> > client(SIGKILL) i can see that "some pending messages" get dumped and
>>> sent
>>> > to the Server ( REQ Part) maybe something jams the device or i have a
>>> > misconfig ?
>>> >
>>>
>>> You seem to use single REQ socket for multiple requestors, right?
>>> Either use XREQ socket or create a socket per greenlet.
>>>
>>> --
>>> Paul
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120420/b0940011/attachment.htm>