An email discussion which took
place on Monday 06.11.2006 (US Style 11.06.2006 ;-)).
Please read it from top to
bottom.
From: Jaworowski, Piotr
Sent: Friday, November 03, 2006 11:31 AM
To: O'Flynn, Dennis
Cc: Everitt, Glenn; Okraszewski, Marcin
Subject: ProjectContainerProxy basic error handling
Hi Dennis,
Today we were testing corona, and we have encountered quite
a few problems connected
with error handling in ProjectContainerProxy.
I know that now is the
stabilization phase of the project, but I've
implemented "basic"
error handling within PCP, and I'm not sure whether
I should check the change
into the CVS repository or not.
That "basic" error
handling fix the problem connected with corona
server which has to run
prior starting the corona client.
Unfortunately, it does not solve problems like losing
connection to server during
the work... Should I check that change into
repository?
Piotr
Ps. we were trying to avoid
introducing big changes to corona lately
but it seams to be a must. As
an attachment, patch with that change.
From:
Everitt, Glenn
Sent:
Friday, November 03, 2006 11:17 PM
To:
Jaworowski, Piotr
Cc:
Hawkins, Joel; Jaworowski, Piotr; Kaczmarek, Pawel; Kalka, Edyta; O'Flynn,
Dennis; Okraszewski, Marcin; Roberts, Brian; Wright, Jim
Subject:
RE: ProjectContainerProxy basic error handling
It seems like the next steps missing.
I think there are two types of exceptions
1. an exception where I want to attempt to
reconnect – in the “catch” of the exception I want to call
some standard re-connection code in the ProjectContainerProxy. A lostConnection
Notification should be sent out if re-connection attempts fail and
lostConnection Notification listeners should disable items in the user
interface and in a perfect world we need to “automatically” switch
over to using the locally cached ContextContainer. Switching over to the
cached ContextContainer implies that the cache has been kept current with the
remote ContextContainer. This may mean the ContextContainer Editor needs
to update the cached container in addition to the remote container.
2. an exception from which there is no
recovery – more thought required here.
So I don’t think this code can be
quickly implemented so in the interim it would make sense to make a
re-connection attempt and if it fails show the exception in a Pop-up
Window/Dialog.
Does this make sense?
Glenn Everitt
From: Okraszewski, Marcin
Sent: Monday, November 06, 2006 12:37 PM
To: Everitt, Glenn
Cc: Jaworowski, Piotr; Hawkins, Joel; Kaczmarek, Pawel; Kalka, Edyta; O'Flynn,
Dennis; Roberts, Brian; Wright, Jim
Subject: Re: ProjectContainerProxy basic error handling
As I understand the re-connection code would be embeded in the
ProjectContainerProxy. So if a method fails it tries to reconnect and
invoke it again. When it fails again it throws an exception. I believe
there is no point in throwing that kind of exception to the invoker,
and
make it handle reconnection. The reconnection should be transparent.
The change of throwing CoronaException in each proxy method will be
required anyway. For now, until the reconnection is implemented, the
lost connection is an unrecoverable error and it is thrown outside. It
helps at least that you can for instance close Eclipse or change server
if the current one doesn't work. Now I experienced things like need to
kill Eclipse when our server goes offline.
So think of all thrown exeptions now as unrecoverable. Later, when we
implement some error handling in the proxy, we will throw less and less
exceptions.
Marcin
From: Jaworowski, Piotr
Sent: Monday, November 06, 2006 8:15 AM
To: Okraszewski, Marcin; Everitt, Glenn
Cc: Hawkins, Joel; Kaczmarek, Pawel; Kalka, Edyta; O'Flynn,
Dennis; Roberts, Brian; Wright, Jim
Subject: RE: ProjectContainerProxy basic error handling
Hi,
I've enhanced that 'basic
error handling' which was written before, so now it would also handle
situations like, connection to server lost during the work.
What was changed :
1)
All
the methods from IConrainerManager are throwing CoronaException,
2)
All
the methods from IProjectConrainerManager are throwing CoronaException,
3)
SOAClientException
inherits CoronaException, (thanks to points 1, 2, 3 no
UndeclaredThrowableException will be thrown, if there is no connection to the
server as exceptions are wrapped by SOAClientException)
4)
All
ProjectContainerProxy are throwing CoronaException
5)
Handling
of newly thrown exceptions added. (Basic handling ;))
Thanks to this, no more
eclipse kill is required if connection fails. All the error messages are logged
into eclipse error log, so user will have the overview what has happened
(connection refused or some other bug).
It would be really good to
add this change to M5. I will not check it in yet. I'd like to know your
opinion first.
All the other stuff like
reconnection in PCP and so on can be implemented within M7 version.
Cheers,
Piotr
Ps. Change as patch, you can
patch your workspace and test it a little bit to see how it works... till now I
didn't find any "serious" errors in it.
From: Hawkins, Joel
Sent: Monday, November 06, 2006 3:13 PM
To: Jaworowski, Piotr; Okraszewski, Marcin; Everitt, Glenn
Cc: Kaczmarek, Pawel; Kalka, Edyta; O'Flynn, Dennis; Roberts, Brian; Wright,
Jim
Subject: RE: ProjectContainerProxy basic error handling
Can someone catch me up here? What exactly is/are the problem(s) we're
trying to solve?
I think I see two.
1. Knowing the difference between a network error and an application
error.
2. Resolving the appropriate error type. The Unknown Exception Types occur
when the proxy can't resolve or construct the returned Exception type.
Making the proxy dependent on CoronaCore gets you around problem 2 iff
your exception type is declared in CoronaCore, but will fail for exception
classes that are not part of CoronaCore. Perhaps a better plan would be to use
the proxied interface's class loader to attempt to load the exception class
from? Reading the code, we're currently using Class.forName(). If we changed it
to something like proxyClass.getClassLoader().loadClass(exceptionName).newInstance()
(with the appropriate error handling and perhaps some code to invoke a
constructor with a message).
This sort of solution would reduce inter-dependencies, and put
responsibility for exception packaging on the proxy requestor, where it
belongs.
Problem 1 sounds like a need to differentiate the SOAClientException.
Perhaps introducing a SOAClientCommunicationException?
Thoughts?
Joel
From: Jaworowski, Piotr
Sent: Monday, November 06, 2006 4:57 PM
To: Hawkins, Joel; Okraszewski, Marcin; Everitt, Glenn
Cc: Kaczmarek, Pawel; Kalka, Edyta; O'Flynn, Dennis; Roberts, Brian; Wright,
Jim
Subject: RE: ProjectContainerProxy basic error handling
Currently, the main problem
is that if anything goes wrong on/with server side, client receives the
UndeclaredThrowableException which is runtime exception. ( client is
implemented in the way that it catches only declared exceptions ).
Such situation causes
problems with closing eclipse instance (you have to kill it, to exit) and does
not allow user to work with corona. The solution I've send should be considered
as a temporary one, thanks to this M5 version would look more stable, and that
it's more user friendly.
> Making the proxy
dependent on CoronaCore gets you around problem 2 if
> your exception type is
declared in CoronaCore, but will fail for
> exception classes that
are not part of CoronaCore.
I almost agree with you in
this point ;-), unfortunately we have to have some root exception defined, and
that this exception should be thrown by all methods defined in
IProjectContainerManager/IContainerManager. Otherwise we will have the
UndeclaredThrowableException problem. For now the problem was that invoke
method wanted to throw SOAClientException for methods which don't declare to
throw it. (We can always define for IContainerManager methods that they throw
Exception or even Throwable, but I'm not sure if it's a good way).
> Reading the code, we're
currently using Class.forName(). If we changed
> it to something like
>
proxyClass.getClassLoader().loadClass(exceptionName).newInstance()
> (with the appropriate
error handling and perhaps some code to invoke a
> constructor with a
message).
This is it :), I really like
that solution.
If it will not work, I
thought about solution similar to AxisFault exception. That CoronaException
would have a cause exception defined in description, and that client has
something like a factory class which creates proper exception from the
description (but this is just in case the proxyClass line won't work).
Cheers,
Piotr
From: Hawkins, Joel
Sent: Monday, November 06, 2006 5:11 PM
To: Jaworowski, Piotr; Okraszewski, Marcin; Everitt, Glenn
Cc: Kaczmarek, Pawel; Kalka, Edyta; O'Flynn, Dennis; Roberts, Brian; Wright,
Jim
Subject: RE: ProjectContainerProxy basic error handling
>Such situation causes problems with closing eclipse instance (you
have to >kill it, to exit) and does not allow user to work with corona.
Whah? There are other ways to get runtime exceptions (like our old
buddy NullPointerException) - so there's no handling that deals with Throwable?
>> Making the proxy dependent on CoronaCore gets you around
problem 2 if
>> your exception type is declared in CoronaCore, but will fail
for >>exception classes that are not part of CoronaCore.
>I almost agree with you in this point ;-), unfortunately we have to
have >some root exception defined, and that this exception should be thrown
by >all methods defined in IProjectContainerManager/IContainerManager.
Sounds like you DO agree with me on this point. :-)
>> Reading the code, we're currently using Class.forName(). If we
changed it
>> to something like
>>
proxyClass.getClassLoader().loadClass(exceptionName).newInstance() (with
>> the appropriate error handling and perhaps some code to invoke
a
>> constructor with a message).
>This is it :), I really like that solution.
>If it will not work, I thought about solution similar to AxisFault
>exception. That CoronaException would have a cause exception defined in
>description, and that client has something like a factory class which
>creates proper exception from the description (but this is just in case the
>proxyClass line won't work).
This is really pretty easy to implement. Shall I make the change? Also,
the SOAClientException carries the reason from the AxisFault. My intent was not
to surface the AxisFault too directly, as we may very well swap out the SOAP
layer in the future (or at least support multiple SOAP layers).
Joel
From: Jaworowski, Piotr
Sent: Monday, November 06, 2006 5:33 PM
To: Hawkins, Joel; Okraszewski, Marcin; Everitt, Glenn
Cc: Kaczmarek, Pawel; Kalka, Edyta; O'Flynn, Dennis; Roberts, Brian; Wright,
Jim
Subject: RE: ProjectContainerProxy basic error handling
>Whah? There are other ways to get runtime exceptions (like our old
buddy >NullPointerException) - so there's no handling that deals with
Throwable?
In most cases there is a standard eclipse handling, that the error
message will go to the eclipse error log. But not in all cases :-(.
> This is really pretty easy to implement. Shall I make the change?
Also,
> the SOAClientException carries the reason from the AxisFault. My
intent
> was not to surface the AxisFault too directly, as we may very well
swap
> out the SOAP layer in the future (or at least support multiple
SOAP
> layers).
The problem is that M5 is coming and I'm not sure if we should add it
or not ;-).
What do you suggest? What exception should be thrown from methods
declared in IContainerManager (Exception, CoronaException, some other) ??
Piotr,
From: Hawkins, Joel
Sent: Monday, November 06, 2006 5:39 PM
To: Jaworowski, Piotr; Okraszewski, Marcin; Everitt, Glenn
Cc: Kaczmarek, Pawel; Kalka, Edyta; O'Flynn, Dennis; Roberts, Brian; Wright,
Jim
Subject: RE: ProjectContainerProxy basic error handling
As far as the proxyClass delegation stuff, it's a one-liner. I say we
go for it. As for distinguishing communication errors, I think I just need to
get a bit more familiar with the AxisFault types so I can tell what comes from
the send chain vs the receive chain.
I do think our code should be able to withstand a runtime exception,
however. No matter what, we shouldn't require a kill -9 to shut down!
Cheers,
Joel
From: Jaworowski, Piotr
Sent: Monday, November 06, 2006 6:03 PM
To: Hawkins, Joel; Okraszewski, Marcin; Everitt, Glenn
Cc: Kaczmarek, Pawel; Kalka, Edyta; O'Flynn, Dennis; Roberts, Brian; Wright,
Jim
Subject: RE: ProjectContainerProxy basic error handling
> No matter what, we shouldn't require a kill -9 to shut down!
That's no problem it's small change within
CoronaWorkbenchListener.preShutdown method, line
PCXViewManager.getManager().hideAndCloseProjects()
was causing the problem with closing the workbench.
It will be surrounded with try catch block...
Piotr,
From: Hawkins, Joel
Sent: Monday, November 06, 2006 9:19 PM
To: Jaworowski, Piotr; Okraszewski, Marcin; Everitt, Glenn
Cc: Kaczmarek, Pawel; Kalka, Edyta; O'Flynn, Dennis; Roberts, Brian; Wright,
Jim
Subject: RE: ProjectContainerProxy basic error handling
OK Piotr, I checked in the change to have the proxyClass resolve the
remote exception type. So the behavior you should see now is:
A: The remote code was invoked, and an exception was thrown that is
declared in the proxy interface, or is visible to the proxy interface's
classloader - you'll get the declared exception.
B: The remote code was invoked, and an exception was thrown that wasn't
declared in the proxy interface, and is not visible to the proxy interface's
classloader - you'll get a SOAClientException.
C: The remote code was never invoked, there was a communication error -
you'll get a SOAClientException.
I've added some code to the SOAClientException so that you can query to
see if the error is a network error and if the error is recoverable. So things
like a miss-configured axis won't be recoverable, but things like a connection
refused will be (in other words, server is unavailable but may return). I don't
have the code in the proxy to populate these fields, so for now everything
defaults to recoverable non-network error.
I'll try and get the detail code into the SOAClientException shortly.
Cheers,
Joel
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.