Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Riena » How does riena communications manage exceptions
How does riena communications manage exceptions [message #14033] Wed, 08 October 2008 09:46 Go to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi,

So far it seems to me that Riena swallows all underlying exceptions
while obtaining a remote reference. It simply returns a null reference
if it cannot create it. Is this accurate? My concern is that there is
no way to discriminate between the myriad of different reasons that a
connection failed, e.g. the was no network, the connection parameters
are incorrect, the host was down, the server was not running, the
requested service is not available, etc.

Is the behaviour during calling a remote interface similar or do they
throw a remote exception if the call cannot succeed due to network
problems?

Thanks,
Joel
--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: How does riena communications manage exceptions [message #14068 is a reply to message #14033] Wed, 08 October 2008 12:23 Go to previous messageGo to next message
Christian Campo is currently offline Christian CampoFriend
Messages: 597
Registered: July 2009
Senior Member
Creating a Remote Service Proxy is an asynchronous process that either gets triggered by specifying properties when you
register an OSGi Service or by calling Publish. The point is its asynchronous in a different thread and sometimes even
an ongoing process triggered by a ServiceListener. So there is no technical mean to actually return to the caller and
say we couldnt create the proxy. For example you might wonna create a proxy for a hessian protocol and the proxy factory
for hessian (or that bundle) is not startet. It gets started later and then the proxy gets created. That works so again
no easy way to come back and say there is a problem. Registering a proxy does however not create a connection, check for
network, host reachability or anything. Remote Services are connection-less and stateless.

When you call a method in the remote Service and you cant reach the host or anything goes wrong in communication you get
a universal Remote Exception than has enclosed the reason (ConnectException) the reason for what went wrong.

The concept in Riena is that you as the user of remote service cant do that much if a remote service goes wrong. So we
will (have not completed that yet) have a universal exception concept (ExceptionHandler) were all uncaught or caught
exception will end up. So, once that is finished, you could decide not too worry about Remote Exceptions but rather have
a global exceptionhandler that deals with remote exception and shows a dialog to tell the user there is something
wrong with his host or for specific calls overwrite that global handler and do something different.

does that sound like a plan ? :-)

christian


Joel Rosi-Schwartz schrieb:
> Hi,
>
> So far it seems to me that Riena swallows all underlying exceptions
> while obtaining a remote reference. It simply returns a null reference
> if it cannot create it. Is this accurate? My concern is that there is no
> way to discriminate between the myriad of different reasons that a
> connection failed, e.g. the was no network, the connection parameters
> are incorrect, the host was down, the server was not running, the
> requested service is not available, etc.
>
> Is the behaviour during calling a remote interface similar or do they
> throw a remote exception if the call cannot succeed due to network
> problems?
>
> Thanks,
> Joel
Re: How does riena communications manage exceptions [message #14102 is a reply to message #14068] Wed, 08 October 2008 12:32 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
That brilliant. It exceeds my expectations and makes my life just a
little bit easier. Thanks!!! :-)

What is your milestone on the Universal Exception Handler? I am asking
for informational purposes, so I can schedule my deferred exception
handling around your timelines. Once you have the strategy worked out,
it would be great if you could share your architecture/design thoughts
to give us an more concrete picture of which way this will be going.

Yes, definitely a very good plan :-)

Cheers,
Joel

On 2008-10-08 13:23:08 +0100, Christian Campo
<christian.campo@compeople.de> said:

> Creating a Remote Service Proxy is an asynchronous process that either
> gets triggered by specifying properties when you register an OSGi
> Service or by calling Publish. The point is its asynchronous in a
> different thread and sometimes even an ongoing process triggered by a
> ServiceListener. So there is no technical mean to actually return to
> the caller and say we couldnt create the proxy. For example you might
> wonna create a proxy for a hessian protocol and the proxy factory for
> hessian (or that bundle) is not startet. It gets started later and then
> the proxy gets created. That works so again no easy way to come back
> and say there is a problem. Registering a proxy does however not create
> a connection, check for network, host reachability or anything. Remote
> Services are connection-less and stateless.
>
> When you call a method in the remote Service and you cant reach the
> host or anything goes wrong in communication you get a universal Remote
> Exception than has enclosed the reason (ConnectException) the reason
> for what went wrong.
>
> The concept in Riena is that you as the user of remote service cant do
> that much if a remote service goes wrong. So we will (have not
> completed that yet) have a universal exception concept
> (ExceptionHandler) were all uncaught or caught exception will end up.
> So, once that is finished, you could decide not too worry about Remote
> Exceptions but rather have a global exceptionhandler that deals with
> remote exception and shows a dialog to tell the user there is something
> wrong with his host or for specific calls overwrite that global handler
> and do something different.
>
> does that sound like a plan ? :-)
>
> christian
>
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> So far it seems to me that Riena swallows all underlying exceptions
>> while obtaining a remote reference. It simply returns a null reference
>> if it cannot create it. Is this accurate? My concern is that there is
>> no way to discriminate between the myriad of different reasons that a
>> connection failed, e.g. the was no network, the connection parameters
>> are incorrect, the host was down, the server was not running, the
>> requested service is not available, etc.
>>
>> Is the behaviour during calling a remote interface similar or do they
>> throw a remote exception if the call cannot succeed due to network
>> problems?
>>
>> Thanks,
>> Joel


--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: How does riena communications manage exceptions [message #16737 is a reply to message #14068] Sat, 22 November 2008 18:34 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Christian,

On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
Campo" <christian.campo@compeople.de> wrote:

> Creating a Remote Service Proxy is an asynchronous process that either gets
> triggered by specifying properties when you
> register an OSGi Service or by calling Publish. The point is its asynchronous
> in a different thread and sometimes even
> an ongoing process triggered by a ServiceListener. So there is no technical
> mean to actually return to the caller and
> say we couldnt create the proxy. For example you might wonna create a proxy
> for a hessian protocol and the proxy factory
> for hessian (or that bundle) is not startet. It gets started later and then
> the proxy gets created. That works so again
> no easy way to come back and say there is a problem. Registering a proxy does
> however not create a connection, check for
> network, host reachability or anything. Remote Services are connection-less
> and stateless.
>
> When you call a method in the remote Service and you cant reach the host or
> anything goes wrong in communication you get
> a universal Remote Exception than has enclosed the reason (ConnectException)
> the reason for what went wrong.

If the method on my remote service throws an exception, is that exception
wrapped in the Remote Exception such that is returned by getCause()?

>
> The concept in Riena is that you as the user of remote service cant do that
> much if a remote service goes wrong. So we
> will (have not completed that yet) have a universal exception concept
> (ExceptionHandler) were all uncaught or caught
> exception will end up. So, once that is finished, you could decide not too
> worry about Remote Exceptions but rather have
> a global exceptionhandler that deals with remote exception and shows a
> dialog to tell the user there is something
> wrong with his host or for specific calls overwrite that global handler and do
> something different.

Will the universal exception handler be a part of Riena 1.0? If so do you
know what milestone it will appear in?

Thanks,
Joel
Re: How does riena communications manage exceptions [message #17529 is a reply to message #16737] Sun, 23 November 2008 16:37 Go to previous messageGo to next message
Christian Campo is currently offline Christian CampoFriend
Messages: 597
Registered: July 2009
Senior Member
Joel Rosi-Schwartz schrieb:
> Hi Christian,
>
> On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
> Campo" <christian.campo@compeople.de> wrote:
>
>> Creating a Remote Service Proxy is an asynchronous process that either gets
>> triggered by specifying properties when you
>> register an OSGi Service or by calling Publish. The point is its asynchronous
>> in a different thread and sometimes even
>> an ongoing process triggered by a ServiceListener. So there is no technical
>> mean to actually return to the caller and
>> say we couldnt create the proxy. For example you might wonna create a proxy
>> for a hessian protocol and the proxy factory
>> for hessian (or that bundle) is not startet. It gets started later and then
>> the proxy gets created. That works so again
>> no easy way to come back and say there is a problem. Registering a proxy does
>> however not create a connection, check for
>> network, host reachability or anything. Remote Services are connection-less
>> and stateless.
>>
>> When you call a method in the remote Service and you cant reach the host or
>> anything goes wrong in communication you get
>> a universal Remote Exception than has enclosed the reason (ConnectException)
>> the reason for what went wrong.
>
> If the method on my remote service throws an exception, is that exception
> wrapped in the Remote Exception such that is returned by getCause()?
if your remote service throws an exception you should directly get it just as if it is
a local service
>
>> The concept in Riena is that you as the user of remote service cant do that
>> much if a remote service goes wrong. So we
>> will (have not completed that yet) have a universal exception concept
>> (ExceptionHandler) were all uncaught or caught
>> exception will end up. So, once that is finished, you could decide not too
>> worry about Remote Exceptions but rather have
>> a global exceptionhandler that deals with remote exception and shows a
>> dialog to tell the user there is something
>> wrong with his host or for specific calls overwrite that global handler and do
>> something different.
>
> Will the universal exception handler be a part of Riena 1.0? If so do you
> know what milestone it will appear in?
no plan beyond the "soon" timeframe. among the committers we spoke about that missing
piece recently. so its not forgotten. We are currently finishing the refactoring of the
way the navigationnodes are created and the refactoring of the Application Model.
Are you just curious to see how that is implemented, or have you already implemented a Riena
Remote Service and wait for the exception handling before you do anything serious ?
>
> Thanks,
> Joel
>

christian
Re: How does riena communications manage exceptions [message #17541 is a reply to message #17529] Sun, 23 November 2008 17:00 Go to previous messageGo to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
On 23/11/2008 16:37, in article 492986E1.1070705@compeople.de, "Christian
Campo" <christian.campo@compeople.de> wrote:

> Joel Rosi-Schwartz schrieb:
>> Hi Christian,
>>
>> On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
>> Campo" <christian.campo@compeople.de> wrote:
>>
>>> Creating a Remote Service Proxy is an asynchronous process that either gets
>>> triggered by specifying properties when you
>>> register an OSGi Service or by calling Publish. The point is its
>>> asynchronous
>>> in a different thread and sometimes even
>>> an ongoing process triggered by a ServiceListener. So there is no technical
>>> mean to actually return to the caller and
>>> say we couldnt create the proxy. For example you might wonna create a proxy
>>> for a hessian protocol and the proxy factory
>>> for hessian (or that bundle) is not startet. It gets started later and then
>>> the proxy gets created. That works so again
>>> no easy way to come back and say there is a problem. Registering a proxy
>>> does
>>> however not create a connection, check for
>>> network, host reachability or anything. Remote Services are connection-less
>>> and stateless.
>>>
>>> When you call a method in the remote Service and you cant reach the host or
>>> anything goes wrong in communication you get
>>> a universal Remote Exception than has enclosed the reason (ConnectException)
>>> the reason for what went wrong.
>>
>> If the method on my remote service throws an exception, is that exception
>> wrapped in the Remote Exception such that is returned by getCause()?
> if your remote service throws an exception you should directly get it just as
> if it is
> a local service

That's perfect :-)

>>
>>> The concept in Riena is that you as the user of remote service cant do that
>>> much if a remote service goes wrong. So we
>>> will (have not completed that yet) have a universal exception concept
>>> (ExceptionHandler) were all uncaught or caught
>>> exception will end up. So, once that is finished, you could decide not too
>>> worry about Remote Exceptions but rather have
>>> a global exceptionhandler that deals with remote exception and shows a
>>> dialog to tell the user there is something
>>> wrong with his host or for specific calls overwrite that global handler and
>>> do
>>> something different.
>>
>> Will the universal exception handler be a part of Riena 1.0? If so do you
>> know what milestone it will appear in?
> no plan beyond the "soon" timeframe. among the committers we spoke about that
> missing
> piece recently. so its not forgotten. We are currently finishing the
> refactoring of the
> way the navigationnodes are created and the refactoring of the Application
> Model.
> Are you just curious to see how that is implemented, or have you already
> implemented a Riena
> Remote Service and wait for the exception handling before you do anything
> serious ?

I'm implementing now. The universal exception handling not being ready is
not a show stopper, but it will certainly improve the robustness of the
application when it does become available.

Thanks,
Joel
Re: How does riena communications manage exceptions [message #17673 is a reply to message #17541] Mon, 08 December 2008 15:54 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 597
Registered: July 2009
Senior Member
Joel Rosi-Schwartz schrieb:
> On 23/11/2008 16:37, in article 492986E1.1070705@compeople.de, "Christian
> Campo" <christian.campo@compeople.de> wrote:
>
>> Joel Rosi-Schwartz schrieb:
>>> Hi Christian,
>>>
>>> On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
>>> Campo" <christian.campo@compeople.de> wrote:
>>>
>>>> Creating a Remote Service Proxy is an asynchronous process that either gets
>>>> triggered by specifying properties when you
>>>> register an OSGi Service or by calling Publish. The point is its
>>>> asynchronous
>>>> in a different thread and sometimes even
>>>> an ongoing process triggered by a ServiceListener. So there is no technical
>>>> mean to actually return to the caller and
>>>> say we couldnt create the proxy. For example you might wonna create a proxy
>>>> for a hessian protocol and the proxy factory
>>>> for hessian (or that bundle) is not startet. It gets started later and then
>>>> the proxy gets created. That works so again
>>>> no easy way to come back and say there is a problem. Registering a proxy
>>>> does
>>>> however not create a connection, check for
>>>> network, host reachability or anything. Remote Services are connection-less
>>>> and stateless.
>>>>
>>>> When you call a method in the remote Service and you cant reach the host or
>>>> anything goes wrong in communication you get
>>>> a universal Remote Exception than has enclosed the reason (ConnectException)
>>>> the reason for what went wrong.
>>> If the method on my remote service throws an exception, is that exception
>>> wrapped in the Remote Exception such that is returned by getCause()?
>> if your remote service throws an exception you should directly get it just as
>> if it is
>> a local service
>
> That's perfect :-)
>
>>>> The concept in Riena is that you as the user of remote service cant do that
>>>> much if a remote service goes wrong. So we
>>>> will (have not completed that yet) have a universal exception concept
>>>> (ExceptionHandler) were all uncaught or caught
>>>> exception will end up. So, once that is finished, you could decide not too
>>>> worry about Remote Exceptions but rather have
>>>> a global exceptionhandler that deals with remote exception and shows a
>>>> dialog to tell the user there is something
>>>> wrong with his host or for specific calls overwrite that global handler and
>>>> do
>>>> something different.
>>> Will the universal exception handler be a part of Riena 1.0? If so do you
>>> know what milestone it will appear in?
>> no plan beyond the "soon" timeframe. among the committers we spoke about that
>> missing
>> piece recently. so its not forgotten. We are currently finishing the
>> refactoring of the
>> way the navigationnodes are created and the refactoring of the Application
>> Model.
>> Are you just curious to see how that is implemented, or have you already
>> implemented a Riena
>> Remote Service and wait for the exception handling before you do anything
>> serious ?
>
> I'm implementing now. The universal exception handling not being ready is
> not a show stopper, but it will certainly improve the robustness of the
> application when it does become available.
>
> Thanks,
> Joel
>
We have started to use the existing exceptionhandler and exceptionmanager and refactor it and call it in certain
situations. Its not yet fully functioning but it works for some cases and that will be in M6.

What is working is that you can handle exceptions at certain application boundaries. One is Remote Services where
you can install one or multiple global exception handles in the top servlet that calls all services in the Riena Server.

Another is when the applicationAdvisor calls the Workbench Exception Handler. The same mechanism here.

We are still missing things like exceptions in Eclipse Jobs (they run on seperate threads) and we have to investigate if
there are more.

These are most likely not fixed by M6 which will come out on friday (hopefully)....give and take a few days.....

christian campo
Re: How does riena communications manage exceptions [message #575919 is a reply to message #14033] Wed, 08 October 2008 12:23 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 597
Registered: July 2009
Senior Member
Creating a Remote Service Proxy is an asynchronous process that either gets triggered by specifying properties when you
register an OSGi Service or by calling Publish. The point is its asynchronous in a different thread and sometimes even
an ongoing process triggered by a ServiceListener. So there is no technical mean to actually return to the caller and
say we couldnt create the proxy. For example you might wonna create a proxy for a hessian protocol and the proxy factory
for hessian (or that bundle) is not startet. It gets started later and then the proxy gets created. That works so again
no easy way to come back and say there is a problem. Registering a proxy does however not create a connection, check for
network, host reachability or anything. Remote Services are connection-less and stateless.

When you call a method in the remote Service and you cant reach the host or anything goes wrong in communication you get
a universal Remote Exception than has enclosed the reason (ConnectException) the reason for what went wrong.

The concept in Riena is that you as the user of remote service cant do that much if a remote service goes wrong. So we
will (have not completed that yet) have a universal exception concept (ExceptionHandler) were all uncaught or caught
exception will end up. So, once that is finished, you could decide not too worry about Remote Exceptions but rather have
a global exceptionhandler that deals with remote exception and shows a dialog to tell the user there is something
wrong with his host or for specific calls overwrite that global handler and do something different.

does that sound like a plan ? :-)

christian


Joel Rosi-Schwartz schrieb:
> Hi,
>
> So far it seems to me that Riena swallows all underlying exceptions
> while obtaining a remote reference. It simply returns a null reference
> if it cannot create it. Is this accurate? My concern is that there is no
> way to discriminate between the myriad of different reasons that a
> connection failed, e.g. the was no network, the connection parameters
> are incorrect, the host was down, the server was not running, the
> requested service is not available, etc.
>
> Is the behaviour during calling a remote interface similar or do they
> throw a remote exception if the call cannot succeed due to network
> problems?
>
> Thanks,
> Joel
Re: How does riena communications manage exceptions [message #575965 is a reply to message #14068] Wed, 08 October 2008 12:32 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
That brilliant. It exceeds my expectations and makes my life just a
little bit easier. Thanks!!! :-)

What is your milestone on the Universal Exception Handler? I am asking
for informational purposes, so I can schedule my deferred exception
handling around your timelines. Once you have the strategy worked out,
it would be great if you could share your architecture/design thoughts
to give us an more concrete picture of which way this will be going.

Yes, definitely a very good plan :-)

Cheers,
Joel

On 2008-10-08 13:23:08 +0100, Christian Campo
<christian.campo@compeople.de> said:

> Creating a Remote Service Proxy is an asynchronous process that either
> gets triggered by specifying properties when you register an OSGi
> Service or by calling Publish. The point is its asynchronous in a
> different thread and sometimes even an ongoing process triggered by a
> ServiceListener. So there is no technical mean to actually return to
> the caller and say we couldnt create the proxy. For example you might
> wonna create a proxy for a hessian protocol and the proxy factory for
> hessian (or that bundle) is not startet. It gets started later and then
> the proxy gets created. That works so again no easy way to come back
> and say there is a problem. Registering a proxy does however not create
> a connection, check for network, host reachability or anything. Remote
> Services are connection-less and stateless.
>
> When you call a method in the remote Service and you cant reach the
> host or anything goes wrong in communication you get a universal Remote
> Exception than has enclosed the reason (ConnectException) the reason
> for what went wrong.
>
> The concept in Riena is that you as the user of remote service cant do
> that much if a remote service goes wrong. So we will (have not
> completed that yet) have a universal exception concept
> (ExceptionHandler) were all uncaught or caught exception will end up.
> So, once that is finished, you could decide not too worry about Remote
> Exceptions but rather have a global exceptionhandler that deals with
> remote exception and shows a dialog to tell the user there is something
> wrong with his host or for specific calls overwrite that global handler
> and do something different.
>
> does that sound like a plan ? :-)
>
> christian
>
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> So far it seems to me that Riena swallows all underlying exceptions
>> while obtaining a remote reference. It simply returns a null reference
>> if it cannot create it. Is this accurate? My concern is that there is
>> no way to discriminate between the myriad of different reasons that a
>> connection failed, e.g. the was no network, the connection parameters
>> are incorrect, the host was down, the server was not running, the
>> requested service is not available, etc.
>>
>> Is the behaviour during calling a remote interface similar or do they
>> throw a remote exception if the call cannot succeed due to network
>> problems?
>>
>> Thanks,
>> Joel


--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: How does riena communications manage exceptions [message #577017 is a reply to message #14068] Sat, 22 November 2008 18:34 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Christian,

On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
Campo" <christian.campo@compeople.de> wrote:

> Creating a Remote Service Proxy is an asynchronous process that either gets
> triggered by specifying properties when you
> register an OSGi Service or by calling Publish. The point is its asynchronous
> in a different thread and sometimes even
> an ongoing process triggered by a ServiceListener. So there is no technical
> mean to actually return to the caller and
> say we couldnt create the proxy. For example you might wonna create a proxy
> for a hessian protocol and the proxy factory
> for hessian (or that bundle) is not startet. It gets started later and then
> the proxy gets created. That works so again
> no easy way to come back and say there is a problem. Registering a proxy does
> however not create a connection, check for
> network, host reachability or anything. Remote Services are connection-less
> and stateless.
>
> When you call a method in the remote Service and you cant reach the host or
> anything goes wrong in communication you get
> a universal Remote Exception than has enclosed the reason (ConnectException)
> the reason for what went wrong.

If the method on my remote service throws an exception, is that exception
wrapped in the Remote Exception such that is returned by getCause()?

>
> The concept in Riena is that you as the user of remote service cant do that
> much if a remote service goes wrong. So we
> will (have not completed that yet) have a universal exception concept
> (ExceptionHandler) were all uncaught or caught
> exception will end up. So, once that is finished, you could decide not too
> worry about Remote Exceptions but rather have
> a global exceptionhandler that deals with remote exception and shows a
> dialog to tell the user there is something
> wrong with his host or for specific calls overwrite that global handler and do
> something different.

Will the universal exception handler be a part of Riena 1.0? If so do you
know what milestone it will appear in?

Thanks,
Joel
Re: How does riena communications manage exceptions [message #577133 is a reply to message #16737] Sun, 23 November 2008 16:37 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 597
Registered: July 2009
Senior Member
Joel Rosi-Schwartz schrieb:
> Hi Christian,
>
> On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
> Campo" <christian.campo@compeople.de> wrote:
>
>> Creating a Remote Service Proxy is an asynchronous process that either gets
>> triggered by specifying properties when you
>> register an OSGi Service or by calling Publish. The point is its asynchronous
>> in a different thread and sometimes even
>> an ongoing process triggered by a ServiceListener. So there is no technical
>> mean to actually return to the caller and
>> say we couldnt create the proxy. For example you might wonna create a proxy
>> for a hessian protocol and the proxy factory
>> for hessian (or that bundle) is not startet. It gets started later and then
>> the proxy gets created. That works so again
>> no easy way to come back and say there is a problem. Registering a proxy does
>> however not create a connection, check for
>> network, host reachability or anything. Remote Services are connection-less
>> and stateless.
>>
>> When you call a method in the remote Service and you cant reach the host or
>> anything goes wrong in communication you get
>> a universal Remote Exception than has enclosed the reason (ConnectException)
>> the reason for what went wrong.
>
> If the method on my remote service throws an exception, is that exception
> wrapped in the Remote Exception such that is returned by getCause()?
if your remote service throws an exception you should directly get it just as if it is
a local service
>
>> The concept in Riena is that you as the user of remote service cant do that
>> much if a remote service goes wrong. So we
>> will (have not completed that yet) have a universal exception concept
>> (ExceptionHandler) were all uncaught or caught
>> exception will end up. So, once that is finished, you could decide not too
>> worry about Remote Exceptions but rather have
>> a global exceptionhandler that deals with remote exception and shows a
>> dialog to tell the user there is something
>> wrong with his host or for specific calls overwrite that global handler and do
>> something different.
>
> Will the universal exception handler be a part of Riena 1.0? If so do you
> know what milestone it will appear in?
no plan beyond the "soon" timeframe. among the committers we spoke about that missing
piece recently. so its not forgotten. We are currently finishing the refactoring of the
way the navigationnodes are created and the refactoring of the Application Model.
Are you just curious to see how that is implemented, or have you already implemented a Riena
Remote Service and wait for the exception handling before you do anything serious ?
>
> Thanks,
> Joel
>

christian
Re: How does riena communications manage exceptions [message #577155 is a reply to message #17529] Sun, 23 November 2008 17:00 Go to previous message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
On 23/11/2008 16:37, in article 492986E1.1070705@compeople.de, "Christian
Campo" <christian.campo@compeople.de> wrote:

> Joel Rosi-Schwartz schrieb:
>> Hi Christian,
>>
>> On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
>> Campo" <christian.campo@compeople.de> wrote:
>>
>>> Creating a Remote Service Proxy is an asynchronous process that either gets
>>> triggered by specifying properties when you
>>> register an OSGi Service or by calling Publish. The point is its
>>> asynchronous
>>> in a different thread and sometimes even
>>> an ongoing process triggered by a ServiceListener. So there is no technical
>>> mean to actually return to the caller and
>>> say we couldnt create the proxy. For example you might wonna create a proxy
>>> for a hessian protocol and the proxy factory
>>> for hessian (or that bundle) is not startet. It gets started later and then
>>> the proxy gets created. That works so again
>>> no easy way to come back and say there is a problem. Registering a proxy
>>> does
>>> however not create a connection, check for
>>> network, host reachability or anything. Remote Services are connection-less
>>> and stateless.
>>>
>>> When you call a method in the remote Service and you cant reach the host or
>>> anything goes wrong in communication you get
>>> a universal Remote Exception than has enclosed the reason (ConnectException)
>>> the reason for what went wrong.
>>
>> If the method on my remote service throws an exception, is that exception
>> wrapped in the Remote Exception such that is returned by getCause()?
> if your remote service throws an exception you should directly get it just as
> if it is
> a local service

That's perfect :-)

>>
>>> The concept in Riena is that you as the user of remote service cant do that
>>> much if a remote service goes wrong. So we
>>> will (have not completed that yet) have a universal exception concept
>>> (ExceptionHandler) were all uncaught or caught
>>> exception will end up. So, once that is finished, you could decide not too
>>> worry about Remote Exceptions but rather have
>>> a global exceptionhandler that deals with remote exception and shows a
>>> dialog to tell the user there is something
>>> wrong with his host or for specific calls overwrite that global handler and
>>> do
>>> something different.
>>
>> Will the universal exception handler be a part of Riena 1.0? If so do you
>> know what milestone it will appear in?
> no plan beyond the "soon" timeframe. among the committers we spoke about that
> missing
> piece recently. so its not forgotten. We are currently finishing the
> refactoring of the
> way the navigationnodes are created and the refactoring of the Application
> Model.
> Are you just curious to see how that is implemented, or have you already
> implemented a Riena
> Remote Service and wait for the exception handling before you do anything
> serious ?

I'm implementing now. The universal exception handling not being ready is
not a show stopper, but it will certainly improve the robustness of the
application when it does become available.

Thanks,
Joel
Re: How does riena communications manage exceptions [message #577375 is a reply to message #17541] Mon, 08 December 2008 15:54 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 597
Registered: July 2009
Senior Member
Joel Rosi-Schwartz schrieb:
> On 23/11/2008 16:37, in article 492986E1.1070705@compeople.de, "Christian
> Campo" <christian.campo@compeople.de> wrote:
>
>> Joel Rosi-Schwartz schrieb:
>>> Hi Christian,
>>>
>>> On 08/10/2008 12:23, in article 48ECA62C.8000806@compeople.de, "Christian
>>> Campo" <christian.campo@compeople.de> wrote:
>>>
>>>> Creating a Remote Service Proxy is an asynchronous process that either gets
>>>> triggered by specifying properties when you
>>>> register an OSGi Service or by calling Publish. The point is its
>>>> asynchronous
>>>> in a different thread and sometimes even
>>>> an ongoing process triggered by a ServiceListener. So there is no technical
>>>> mean to actually return to the caller and
>>>> say we couldnt create the proxy. For example you might wonna create a proxy
>>>> for a hessian protocol and the proxy factory
>>>> for hessian (or that bundle) is not startet. It gets started later and then
>>>> the proxy gets created. That works so again
>>>> no easy way to come back and say there is a problem. Registering a proxy
>>>> does
>>>> however not create a connection, check for
>>>> network, host reachability or anything. Remote Services are connection-less
>>>> and stateless.
>>>>
>>>> When you call a method in the remote Service and you cant reach the host or
>>>> anything goes wrong in communication you get
>>>> a universal Remote Exception than has enclosed the reason (ConnectException)
>>>> the reason for what went wrong.
>>> If the method on my remote service throws an exception, is that exception
>>> wrapped in the Remote Exception such that is returned by getCause()?
>> if your remote service throws an exception you should directly get it just as
>> if it is
>> a local service
>
> That's perfect :-)
>
>>>> The concept in Riena is that you as the user of remote service cant do that
>>>> much if a remote service goes wrong. So we
>>>> will (have not completed that yet) have a universal exception concept
>>>> (ExceptionHandler) were all uncaught or caught
>>>> exception will end up. So, once that is finished, you could decide not too
>>>> worry about Remote Exceptions but rather have
>>>> a global exceptionhandler that deals with remote exception and shows a
>>>> dialog to tell the user there is something
>>>> wrong with his host or for specific calls overwrite that global handler and
>>>> do
>>>> something different.
>>> Will the universal exception handler be a part of Riena 1.0? If so do you
>>> know what milestone it will appear in?
>> no plan beyond the "soon" timeframe. among the committers we spoke about that
>> missing
>> piece recently. so its not forgotten. We are currently finishing the
>> refactoring of the
>> way the navigationnodes are created and the refactoring of the Application
>> Model.
>> Are you just curious to see how that is implemented, or have you already
>> implemented a Riena
>> Remote Service and wait for the exception handling before you do anything
>> serious ?
>
> I'm implementing now. The universal exception handling not being ready is
> not a show stopper, but it will certainly improve the robustness of the
> application when it does become available.
>
> Thanks,
> Joel
>
We have started to use the existing exceptionhandler and exceptionmanager and refactor it and call it in certain
situations. Its not yet fully functioning but it works for some cases and that will be in M6.

What is working is that you can handle exceptions at certain application boundaries. One is Remote Services where
you can install one or multiple global exception handles in the top servlet that calls all services in the Riena Server.

Another is when the applicationAdvisor calls the Workbench Exception Handler. The same mechanism here.

We are still missing things like exceptions in Eclipse Jobs (they run on seperate threads) and we have to investigate if
there are more.

These are most likely not fixed by M6 which will come out on friday (hopefully)....give and take a few days.....

christian campo
Previous Topic:Documentation on Riena navigation
Next Topic:Riena 1.0.0.M6 is coming on FRIDAY
Goto Forum:
  


Current Time: Thu Mar 28 16:38:31 GMT 2024

Powered by FUDForum. Page generated in 0.05685 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top