[
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.
|
I forgot to include
[1] http://en.wikipedia.org/wiki/Actor_model
Scott Lewis wrote:
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev