<div dir="ltr">Hey guys,<br><br>What is the right way to use zeromq in high reliability environments?  In<br>certain insane/impossible situations (e.g. out of memory, out of file<br>descriptors, etc) libzmq assertions will fail and it will abort.<br>
<br>I came across a thread by Martin where he addresses a similar situation [1].  If<br>I'm reading his argument correctly, the gist in general is: If it's impossible<br>to connect due to some error, than you're dead in the water anyways.  Crash<br>
loudly and immediately with the error (the Fail-Fast paradigm), fix the error,<br>and then restart the process.<br><br>I actually agree with this philosophy, but a user would say "You terminated my<br>entire application stack and didn't give me a chance to cleanup!  I had very important data<br>
in memory and it's gone!"  This is especially the case with Java programmers who<br>Always Expect an Exception.<br><br>For example, in the case of being out of file descriptors, the jzmq bindings will abort,<br>but a Java programmer would expect to get an Exception with the "Too Many Open<br>
Files" error.<br><br>I guess one possible retort is: if the data in memory was so important, why<br>didn't you have redundancy/failover/some kind of playback log? Why did you put<br>all your eggs in one basket assuming your process would never crash?<br>
<br>Is that the right answer here (basically blame the user for not having disaster<br>recovery), or is there a different/better way to address the high reliability<br>scenario?<br><br>I came across another thread where Martin gets this very<br>
complaint (zeromq aborted my application!), and basically says well, if you really, really want to,<br>you can install a signal handler for SIGABRT, but caveat emptor [2].<br><br>To me, this is playing with fire, dangerous, and just a Bad Idea. But maybe it's<br>
worth the risk in high reliability environments?<br><br><br>Thanks in advance for any advice or thoughts.<br><br>[1] <a href="http://lists.zeromq.org/pipermail/zeromq-dev/2009-May/000784.html">http://lists.zeromq.org/pipermail/zeromq-dev/2009-May/000784.html</a><br>
[2] <a href="http://lists.zeromq.org/pipermail/zeromq-dev/2011-October/013608.html">http://lists.zeromq.org/pipermail/zeromq-dev/2011-October/013608.html</a><br><br></div>