PyZMQでキューの長さを制限する

Question

PythonアプリケーションでZeroMQメッセージキューが消費するメモリ量を制限します。最高水準点を設定すると、送信側でキューに入れられる量が制限されますが、受信側でどのくらいキューに入れられるのかを制御する方法はありますか？ PythonのZeroMQバインディングは無制限に設定されているようです。

私のテストシナリオ：テスト用に使用しているPython端末が2つあります。一つは、受信機である：

Python 2.5.1 (r251:54863, Aug 25 2008, 20:50:04) 
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import zmq.core 
>>> context=zmq.Context() 
>>> socket = context.socket(zmq.PULL) 
>>> socket.setsockopt(zmq.RCVBUF, 256) 
>>> socket.bind("tcp://127.0.0.1:12345") 

他の者が送信者である：

Python 2.5.1 (r251:54863, Aug 25 2008, 20:50:04) 
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import zmq.core 
>>> context=zmq.Context() 
>>> socket = context.socket(zmq.PUSH) 
>>> socket.setsockopt(zmq.SNDBUF, 2048) 
>>> socket.setsockopt(zmq.HWM, 1) 
>>> socket.connect("tcp://127.0.0.1:12345") 
>>> num = 0 
>>> while True: 
... print num 
... socket.send(str(num)) 
... num = num + 1 
... 

私は聞かせて、キューが動作することを確認し、それ以外にするために、受信側で数回をsocket.recv()を実行します2つの端末がそこに座っているだけです。 sendループは決してブロックされないようで、受信プロンプトはメモリ占有量が増えているようです。

Answer 1

ZeroMQのドキュメントとは対照的に、最高水準点はPUSH側とPULL側の両方に設定する必要があります。私がPULLを変更した後、それはより良く機能しました。新しいPULLコードは次のとおりです。

Python 2.5.1 (r251:54863, Aug 25 2008, 20:50:04) 
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import zmq.core 
>>> context=zmq.Context() 
>>> socket = context.socket(zmq.PULL) 
>>> socket.setsockopt(zmq.RCVBUF, 256) 
>>> socket.setsockopt(zmq.HWM, 1) 
>>> socket.bind("tcp://127.0.0.1:12345") 

Answer 2

実は、ドキュメントがこれを言う：

「ZMQ_PUSHソケットが原因 すべての下流ノードのためのハイウォーターマークに達した、または有することに例外状態に入ると ダウンストリームノードがまったく存在しない場合、 ソケットのzmq_send（3）操作は、例外状態が終了するか、少なくとも1つのダウンストリームノードが送信可能になるまでブロックされます; は破棄されません。

あからさまなあなたが（とすべきである）（別名プル）の下流ノードのためのハイウォーターマークを設定し、そしておそらくプッシュ側でそれを設定する（が、効果がないことを意味することができますことを述べ

http://api.zeromq.org/2-1:zmq-socket

ダウンストリームノードは利用可能であるが、メッセージは送信できるよりも速く入ってくるケースがまだ存在するため、これは真実ではないと思われる。