i guess what i'm saying is that acks caught in tcp buffer create a
dangerous situation when your client dies (or is manually stopped).
the work is done but never acked. when the buffer consists of a 1000
acks, that's a lot of lost but completed work. i imagine that moving
to non-blocking libraries would minimize the delay, but it still seems
like you'll lose work. maybe i'm wrong. it's a difficult theory to
test without converting my entire application to use em.
i'm surprised more people don't run into this issue. i'm not doing
anything special with the client.
but thanks again for the advice. very helpful.
On Feb 12, 12:31 pm, Aman Gupta <
themastermi...@gmail.com> wrote:
> there are two solutions to this problem:
>
> one is to use asynchronous libraries for everything such that there
> are never any blocking actions. you can use em-mysql
> (
http://github.com/tmm1/em-mysql) to access a mysql database,
> eventedcache (
http://github.com/cliffmoon/eventedcache) for memcache
> access and EM::P::SmtpClient to send emails.
>
> the other is use use ruby threads to run your blocking code, such that
> the main reactor can still continue to run alongside instead of
> getting blocked as well. you can do this using EM.defer:
>
> MQ.queue('name').subscribe{ |info, msg|
> EM.defer(proc{
> process(msg)
> }, proc{
> info.ack
> })
>
> }
>
> Aman
>