There''s a ticket open for this at http://rubyeventmachine.com/ticket/79
Any suggestions for what the argument would be in the different cases?
The three cases I usually deal with in my client code are:
- connecting for the first time and failed (raise an error)
- connected once already and got disconnected (reconnect)
- reconnect attempt failed (try reconnect again)
which ends up looking something like:
def connection_completed
@reconnecting = false
@connected = true
end
def unbind
if @connected or @reconnecting
EM.add_timer(1){ reconnect @host, @port }
@connected = false
@reconnecting = true
else
raise ''Unable to connect to server''
end
end
This also handles the ''reactor going down'' case properly
because the
reconnect happens via a timer which is never fired.
When dealing with reconnects, I''ve also found it helpful to make my
connection a Deferrable. The status of the deferrable reflects the
current connected state, so I can simply:
include EM::P::Deferrable
def connection_completed
succeed
end
def unbind
@deferred_status = nil
end
def send_data data
callback{ super(data) }
end
This way, outgoing packets are queued up whenever the client is the
@connected=false or @reconnecting=true state.
Aman
On Sun, Feb 15, 2009 at 7:59 AM, Colin Steele <cvillecsteele at gmail.com>
wrote:> There was some talk previously (here:
> http://rubyforge.org/pipermail/eventmachine-talk/2007-December/001305.html)
> about providing a notion of the reason for an unbind. I''d like to
revive
> that request. I love EM''s simplicity, but I think this is a case
where
> simplicity isn''t sacrificed by adding an arity check on unbind and
passing
> in a reason code.
>
> Thoughts?
>
> --
> Colin Steele
> www.colinsteele.org
> cvillecsteele at gmail.com
> Ken Kesey - "Ritual is necessary for us to know anything."
>
> _______________________________________________
> Eventmachine-talk mailing list
> Eventmachine-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/eventmachine-talk
>