[zeromq-dev] Python / Zmq / Gevent
Antonio Teixeira
eagle.antonio at gmail.com
Fri Apr 20 16:16:24 CEST 2012
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/da4727ea/attachment.htm>
More information about the zeromq-dev
mailing list