DRb::DRbObject.alive?

Ruby
1

Hi,

I found a feature that seem to be missing to me in DRb.

I’m just creating a chat with a client and a server, using only DRb to
interact between them.

My problem is I didn’t found a nice way to verify if a client is alive.
I would like to be able to update my clients’ list, but I need to know
if
they are alive.

Currently, I’m getting around with catching the Exception
DRb::DRbConnError,
but that looks really ugly:
@clients.each { |c|
begin
c.respond_to?(:some_method_defined_in_client) #Trying to use any
method
of c will raise the exception (except if not defined)
rescue DRb::DRbConnError
@clients.delete©
end
}

Using Exceptions would be meaningful when I try to send(it would raise
the
exception if I call #send), but then I would have to manage Exceptions
everywhere.

The method alive? is defined for the DRbServer and DRbTCPSocket, but not
for
DRbObject! (in fact if the Client just got disconnected, alive? will
still
return true)

Does somebody already met this? (And does somebody knows what DRb is?^^
Please have a look it’s pretty cool, but the documentation could even be
better…)

Benoit

2

On 11/25/2009 12:04 AM, Benoit D. wrote:

but that looks really ugly:
exception if I call #send), but then I would have to manage Exceptions
everywhere.

Well, but this is the usual approach.

The method alive? is defined for the DRbServer and DRbTCPSocket, but not for
DRbObject! (in fact if the Client just got disconnected, alive? will still
return true)

It should not be too difficult to add method alive? to DRbUndumped.
However, there is a more fundamental problem that cannot be solved: even
if you have method alive? and it is working properly what does it tell
you? It tells you that the object was alive when you invoked that
method. You have no guarantees that it will be alive when you make the
next remote method call. Hence you need to handle exceptions anyway.
Now you have exception handling plus additional code that checks
liveness beforehand. Your code is complexer and slower.

Does somebody already met this?

This is a common issue people stumble over all the time (typically with
things that involve interprocess communication such as for database
connections and the like). The issue is always the same: you do not
gain anything with this method because you have to deal with failure
anyway.

Kind regards

robert

3

Yeah, you’re right.

So here’s how I did to not duplicate the code:

 def try_on_clients
    @clients.each { |client|
        begin
            yield client
        rescue DRb::DRbConnError
            del_drb_client(client)
        end
    }
end

def receive_message(msg)
    try_on_clients { |client| client.show_message(msg) }
end

That looks already more beautiful, and doesn’t spend time looking if
alive.
Anyway, it’s a little too bad for the client, because any connection
error
will drop him away, but he can reconnect easily.

Regards,
Benoit

2009/11/25 Robert K. [email protected]

4

2009/11/25 Benoit D. [email protected]:

       end
   }

end

def receive_message(msg)
try_on_clients { |client| client.show_message(msg) }
end

That looks already more beautiful, and doesn’t spend time looking if alive.
Anyway, it’s a little too bad for the client, because any connection error
will drop him away, but he can reconnect easily.

Well, you could place them in a closed list (or queue) or even return
the array of closed / removed clients.

Kind regards

robert