4 ms·

Why wouldn't you want to use a DB queue or something, and have a separate cronjob / process the outgoing email?

• morgo 15y ago
  A queue is FIFO oriented, a database is least-recently-used (LRU). It works, but is not going to be the most efficient tool. Where a queue is really useful is converting from foreground to background, so that you can optimize for throughput, rather than having to leave free capacity for 'random arrivals' of your foreground servers. Think of it as the same as the same problem as the bursty traffic that a bank machine gets, and why you always seem to have to line up. The mathematical term is Poisson distribution: http://en.wikipedia.org/wiki/Poisson_distribution http://en.wikipedia.org/wiki/Poisson_distribution
  • mibbitier 15y ago
    DB table "pending_emails" with a time field... cronjob removes them based on time entered, and sends them. shrug
    • morgo 15y ago
      http://www.engineyard.com/blog/2011/5-subtle-ways-youre-using-mysql-as-a-queue-and-why-itll-bite-you/ http://www.engineyard.com/blog/2011/5-subtle-ways-youre-usin...
• harrylove 15y ago
  With this commit, you can if you want. This code decouples Rails from external queue solutions. If your application needs to interact with a queue, you only have to write it once and you can use a standard API to do it. If your external queue solution (your DB queue code) conforms to the API, you can switch it out with another conforming solution when your needs call for it. As someone pointed out in the OP comments, this is like Rack for queues.