again, this would be easy to diagnose if only there were a plausible (if not completely accurate) way to determine the number of queued messages.
On May 8, 2011, at 11:26 PM, Martin Sustrik wrote: > Hi Blair, > >> On 9 May 2011 15:40, Martin Sustrik<sust...@250bpm.com> wrote: >>> It should be acknowledged though that OOMs are easier to debug than >>> deadlocks. However, debugging is not exactly newbie activity. It's >>> likely to be performed by more experienced users which should be aware >>> of an option of setting HWM to infinity to induce OOMs. >>> >>> Thoughts? >> >> An experienced programmer coming to 0MQ is likely to attempt their own >> debugging, so what do you mean by newbie? > > A new person trying the simplest possible use case. Publish messages in > a loop: Oh my, it's out of memory! Let's switch to some more reasonable > messaging system! > >> +1 for Pieter's context config option. I think I agree having a >> default HWM would be good, however, only if HWM events are easily >> exposed. > > The context options are a different issue. They are completely > orthogonal to what the default for HWM should be. Let's discuss them in > a separate thread. > >> As an aside, any idea of the 0MQ behaviour under flooding with no HWM >> but sane kernel virtual memory settings (i.e., >> /proc/sys/vm/overcommit_memory=2)...? > > Sorry, no experience, however, when publisher is publishing faster than > receiver is receiving the size of the queue grows without limit. In such > case no tuning is going to help. > > Martin > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev ------------------ Andrew Hume (best -> Telework) +1 623-551-2845 and...@research.att.com (Work) +1 973-236-2014 AT&T Labs - Research; member of USENIX and LOPSA
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
