Skip to main content

[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



Back to the top