<div dir="ltr">At-least-once semantics is one of the reasons to look beyond Resque/Sidekiq once you've moved the overhead of message management off your database (DelayedJob).<div><br></div><div>On a related note Salvatore Sanfilippo (antirez) has been working on Disque which sounds interesting. He published a blog post overnight on how that's going <a href="http://antirez.com/news/88">http://antirez.com/news/88</a></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><b>Garry Shutler</b><div><div><a href="http://twitter.com/gshutler" target="_blank">@gshutler</a></div><a href="http://gshutler.com/" target="_blank">gshutler.com</a></div></div></div></div>
<br><div class="gmail_quote">On 16 March 2015 at 10:01, James McCarthy <span dir="ltr"><<a href="mailto:james@lety.co" target="_blank">james@lety.co</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    I've used and swear by RabbitMQ, avoiding all the DB as a Q
    locking/transaction/commit issues.<br>
    <br>
    Handy thing with RabbitMQ is that it includes an acknowledge
    configuration which can be auto or manual.<br>
    <br>
    With manual, you need to call the acknowledge method before the
    message is removed from the queue.<br>
    <br>
    James.<div><div class="h5"><br>
    <br>
    <div>On 16/03/15 09:12, Najaf Ali wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      <div dir="ltr">Hi all,
        <div><br>
        </div>
        <div>I'm trying to identify some general good practices (based
          on real-life problems) when it comes to working with async job
          queues (think DJ, Resque and Sidekiq).</div>
        <div><br>
        </div>
        <div>So far I've been doing this by collecting stories of how
          they've failed catastrophically (e.g. sending thousands of
          spurious SMS's to your customers) and seeing if I can identify
          any common themes based on those.</div>
        <div><br>
        </div>
        <div>Here are some examples of what I mean (anonymised to
          protect the innocent):</div>
        <div><br>
        </div>
        <div>* Having a (e.g. hourly) cron job that checks if a job has
          been done and then enqueues the job if it hasn't. It knows
          this because the successfully completed job would leave some
          sort of evidence of completion in e.g. the database. If your
          workers go down for a day, this means the same job would be
          enqueued over and over again superfluously.</div>
        <div><br>
        </div>
        <div>* Sending multiple emails (hundreds) in a single job lead
          to a problem where if just one of those emails (say the 24th)
          fails to be delivered, the entire job fails and emails 1-23
          get sent again when your worker retries it again and again and
          again.</div>
        <div><br>
        </div>
        <div>* With the workers/app running the same codebase but on
          different virtual servers, deploying only to the application
          server (and not the server running the workers) resulted in
          the app servers queueing jobs that the workers didn't know how
          to process.  </div>
        <div><br>
        </div>
        <div>It would be great to hear what sort of issues/incidents
          you've come across while using async job queues like the
          above. I don't think I have enough examples to make any
          generalisations about the "right way" to use them yet, so more
          interested in just things that went wrong and how you fixed
          them at the moment.</div>
        <div><br>
        </div>
        <div>Feel free to reply off-list if you'd rather not share with
          everyone, I intend to put the findings together in a blog post
          with a few guesses as to how to avoid these sorts of problems.</div>
        <div><br>
        </div>
        <div>All the best,</div>
        <div><br>
        </div>
        <div>-Ali</div>
        <span></span></div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><span class=""><pre>_______________________________________________
Chat mailing list
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a>
</pre>
    </span></blockquote><span class="HOEnZb"><font color="#888888">
    <br>
    <pre cols="72">-- 
James McCarthy

Software Consultant

LetyCo

Mob:  07577006897

Email:  <a href="mailto:james@lety.co" target="_blank">james@lety.co</a>

<a href="http://lety.co" target="_blank">lety.co</a></pre>
  </font></span></div>

<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org">Chat@lists.lrug.org</a><br>
Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>