[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Time-out Exception and remote services, what is the best practice.
|
Hi Wim,
Wim Jongman wrote:
Hi,
I am working with remote services. If the service is dynamic and can
come and go at any time then there is an issue:
Suppose I have discovered a remote service and I make a call to it.
If, during the call, the remote framework decides to stop the service
then you will get the attached exception.
I really want to make this as transparent as possible and not wrap the
remote service in all kinds of try blocks.
Note this isn't a problem with the ECF software for doing
remoting/distribution...rather it's a problem endemic to *any*
distributed/remoting system (real or imagined :). The root of this is
the fact that the network has certain properties (of timing and partial
failure) that make these things happen...and they do not happen when
there is no network involved (all within a single process).
Of course, many people
have warned about the caveats of remote services but what is the best
way ECF can help ppl to work with them?
In my opinion, the answer to this is to provide people/developers with
additional ways to invoke remote methods...i.e. in addition to blocking
method calls. In ECF, in addition to the completely transparent proxy
(i.e. blocking rpc), we provide
1) Access to changing/setting the timeout duration
2) Asynchronous remote services (both callback style and future style
access)
If there are others that people would want us to consider/add that would
be great. But these are the things that I know of.
If we work with async calls
then we are working with the concept of remote services in our code.
I would disagree that by using asynchronous remote services that you are
working with rs in your code...rather you are are working with async
services...and they just happen to be remote :). Note that in many
multithreaded programs (like Eclipse), asynchronous interaction happens
all the time between threads (e.g. Display.asyncExec).
But of course I'm not denying that you are right Wim...it would be
conceptually much simpler if all method calls (whether remote or not)
could be synchronous/invoked in a single thread-per-process. This
becomes impossible, however, when you distribute method calls across
processes (or even threads). In such cases the developer has to worry
about timing/blocking/deadlock, etc. And timing/concurrency is
extremely hard to deal with IMHO.
Asynchronous models of computing (like the Actor model[1]) are
relatively unfamiliar...precisely because...IMHO...they make programming
arguably more complex...because timing and concurrency play a role at
the API/programmer level. But my belief is that these other models are
needed (not in exclusion to, but rather in addition to 'normal' models)
because in effect we can only try to 'cover up' the characteristics of
the network (wrt timing and concurrency) so much...and the network's
properties end up 'leaking through' abstractions like
blocking/transparent rpc...in the form of timeouts, in the form of
runtime exceptions/failure, and in other ways (performance and
responsiveness issues).
If we work synchronized then we can have the problem described here.
Is there a way for the host to know that the service is in use so it
can wait a little bit.
I'm not sure I understand what you are asking. Do you mean can the host
framework wait to stop a service when some consumer (whether remote or
not) is 'using' the service? If I'm understanding you correctly, this
would be something that OSGi would have to do at the framework level.
Out of the box: It would be ideal if the remote
service would prevent giving out a new instance to requesters but
would allow the consumer to finish a request.
I guess I need to understand what you are thinking a little better...as
I don't think that I completely understand your use case (for the host's
service being taken down) here.
Scott
