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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
