[zeromq-dev] Forwarding ROUTER to PUB

Bruno D. Rodrigues bruno.rodrigues at litux.org
Thu Jan 16 20:10:29 CET 2014


both PUB and ROUTER drop messages.

the HWM is default 1K since v3 if I recall from the documentation. 


On Jan 16, 2014, at 19:03, Lindley French <lindleyf at gmail.com> wrote:

> Well, aside from the router issue I do like the arrangement for easily handling different messages in different places. However, there may be a fatal flaw at the moment: PUB's desire to drop messages at the HWM. While making "drop" a default behavior for PUB is fine, I really don't like that it's the *only* behavior possible.
> 
> Then again, that may or may not be the issue here. I haven't touched the HWM, so it should still be 0 which is theoretically infinite. Nonetheless, a bunch of my messages in a row vanished into the ether somewhere between PUB and SUB inproc sockets.
> 
> 
> On Thu, Jan 16, 2014 at 1:02 PM, Lindley French <lindleyf at gmail.com> wrote:
> I tend to stuff in as many different features as I can when I'm first learning something new, it helps me get a feel for it.
> 
> You should have seen my first major python program.....
> 
> 
> On Thu, Jan 16, 2014 at 12:46 PM, Charles Remes <lists at chuckremes.com> wrote:
> Create a socket for each worker thread and have your main thread resend the message down the appropriate socket. Sometimes it isn’t a good idea to try and shoe-horn every zeromq socket pattern into your app. :)
> 
> On Jan 16, 2014, at 9:54 AM, Lindley French <lindleyf at gmail.com> wrote:
> 
> > A problem I was wrestling with was, how do I deal with a TCP connection where messages of different types may arrive, and may need to be dealt with in different threads? The TCP socket can't be touched directly by multiple threads, of course. The obvious solution was to immediately forward messages arriving on the TCP socket to an inproc socket.
> >
> > I then took it one step further: why not make that inproc socket a PUB socket and make the first part of each message be a topic identifier, so that whichever thread knows how to deal with a particular message can just subscribe to it and ignore the rest?
> >
> > That's a great design, right up until I try to do it with the TCP socket being a ROUTER. Now, no matter what the first part of the sent message is, the identity will end up being the first part on the receiving end. The PUB/SUB won't work without some tweaking.
> >
> > I don't want to just drop the identity; that's useful information. I could swap the first two parts; that will work, but it's unintuitive and could cause confusion down the road.
> >
> > Any other ideas?
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> 
> _______________________________________________
> 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/20140116/e2534d16/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140116/e2534d16/attachment.sig>


More information about the zeromq-dev mailing list