Re: Calling a OneWay method on a remoted object that is not alive
From: Ken Kolda (ken.kolda_at_elliemae-nospamplease.com)
Date: 11/29/04
- Next message: Ken Kolda: "Re: Remoting security"
- Previous message: dr: "Remoting security"
- In reply to: TT (Tom Tempelaere): "Calling a OneWay method on a remoted object that is not alive"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 29 Nov 2004 08:42:23 -0800
If the remoting server isn't running, then every call to a remote method
will cause the client to re-attempt a connection to the server. This
connection attempt can take a little while (especially if it has to time out
due to a firewall). My experience is that even if your call is OneWay, the
connection attempt is performed synchronously at the time of the method call
(assuming the connection succeeds, the actual method call is then done
asynchronously). So, if the server isn't up, the call will block until the
connection fails.
My suggestion would be that you create your own in-memory logging queue that
you post messages to. Then create a thread that services this queue to send
the messages to your server. That would mean you no longer need to use
OneWay methods, which will allow your client app to be more informed as to
the state of the server. If the logging thread determines the logging server
is down, it can simply discard the messages in the queue. It might even
attempt to retry after a certain period of time. As long as the queue
doesn't grow so large that it consumes too much memory, this seems like a
much more robust model and will allow your main app thread on the client to
run unhampered by what occurs on your logging server.
Ken
"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message news:DD21A1C8-1E50-4822-89C8-BECAF3A5530F@microsoft.com...
> Hi,
>
> In my project I have a seperate logging application. I use remoting to log
> to it. The remoted object exposes a certain (log-)interface, and the
methods
> therein are all OneWay methods (decorated with the OneWay attribute).
>
> In my real application, I connect to the remoted log-object (using
> RemotingServices.Connect). This returns a proxy for the remoted object,
which
> I cast to the logging-interface.
>
> This always succeeds because the Connect call simply returns a proxy. So
at
> the point of connection, I cannot deduce whether the remoted object is
> actually alive (or started). Since all the methods in the logging
interface
> are OneWay, calling them always succeeds, so again there is no way of
telling
> whether the remoted object is present.
>
> The problem is the following. I start my application, but not my
> logging-application (which hosts the remoted logging object). My
application
> logs a lot and it calls the methods in the logging-interface without
getting
> remoting-exceptions whatsoever. But after a few method calls on the
> logging-interface, these method calls start to become _very_ slow, so slow
> that my program seems to hang.
>
> I suspect that a call to a OneWay method posts these calls in a queue
> somewhere, and that the queue starts to fill up after a while because the
> queue is never emptied (since my remoted object is not alive).
>
> Anyway, I don't know a solution to this. Does anyone know how to solve
this
> issue?
>
> I thought about making one dummy-method in the interface just to ensure
that
> the logging-application is started. This dummy-method would not be OneWay,
> and if calling it throws a remoting exception then I can just disable the
> logging calls. But that seems more like a workaround and not a real
solution.
>
> Any input is appreciated.
>
> Thanks,
> --
> Tom Tempelaere.
- Next message: Ken Kolda: "Re: Remoting security"
- Previous message: dr: "Remoting security"
- In reply to: TT (Tom Tempelaere): "Calling a OneWay method on a remoted object that is not alive"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
