ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthieu Riou" <matth...@offthelip.org>
Subject Re: Server error handling
Date Sat, 05 Apr 2008 23:01:43 GMT
On Sat, Apr 5, 2008 at 8:26 AM, Alex Boisvert <boisvert@intalio.com> wrote:

> On Sat, Apr 5, 2008 at 7:16 AM, Tammo van Lessen <tvanlessen@gmail.com>
> wrote:
> > we had the same discussion a while ago when I added some code to
> > swallow all exceptions that occur in event handlers. But (I think it
> > was Alex) finally convinced me that event handlers should be capable
> > throw exceptions which result in aborting the transaction. There are
> > several use cases for such an behavior like strict
> > requirements/obligations regarding audit data. In a real-world
> > environment storing audit data in a reliable fashion is an absolute
> > MUST. So in case of a data bases error, network fragmentation,
> > harddisk crash etc, the event listener must be able to interrupt the
> > actual execution because the execution can not be completed in the
> > intended way (i.e. having all events in an audit trail can not be
> > guaranteed anymore).
> It was probably me and I still stand by it ;)
> > Another use case would be "process repair". In
> > case you have received a certain sequence of events you may figure out
> > that the process instance does not behave in the intended way. In such
> > a case you may want to either "repair" variable values or may want to
> > fail the process instance.
> I had not considered this use-case yet;  I think it's an interesting one
> although it would probably need non-trivial work to implement in a way
> that's similar to the current activity recovery mechanism.
> I believe these are convincing points, therefore I suggest to either
> > put the responsibility to catch runtime exceptions to the event
> > handler developer or to introduce a dedicated exception for the
> > explicitly reporting/wrapping an error and swallowing all runtime
> > exceptions in Ode.
> I also assumed it was the responsibility of the event handler to behave...
> although Matthieu seems to think the engine should generalize the
> rollback/ignore behavior.
> But in general I agree that Ode should deal with such an exception in
> > a meaningful manner, i.e. it should create a BPEL fault which then
> > either bubbles back to the client or even could be caught by a BPEL
> > faultHandler.
> So we have 3 cases now,
>   1. Rollback transaction if there's an internal exception related to
>   the event handler and report a failure to outstanding message exchanges
>   instead of timeout
>   2. Ignore internal exceptions related to event handler
>   3. Use a special exception to signify the process should go into some
>   form of recovery/repair mode.
> The second part of #1 is the outstanding bug that Thilina filed.   (And
> there might be a bigger problem if the engine quits as a result; we need
> to
> investigate)
> #2 would possibly be a small enhancement;  Matthieu proposed a change to
> the
> even handler interface.  I was thinking it could be a deployment
> configuration option (at the event handler level).   Or we can leave it as
> it is and assume the event handler swallows all exceptions if desired.
> #3 is a bigger enhancement.  I like the idea but we need a volunteer or
> somebody who has a significant itch.
> Is this a fair assessment?

Sounds fair to me. For #2 I'm of the opinion that it should be part of the
event handler interface as it's something you want the API implementer to be
aware of. So I proposed (in the Jira issue created by Thilina) to add a
method like failOnError() so the handler can signify the expected engine

About #3 I have mixed feeling. This would mandate exposing the engine state
(both the OModel and Jacob) to the outside world, effectively making the
running state a public interface. We can't guarantee the stability of this
interface, we want to able to change it at anytime. So even if self-repair
sounds like a seducing idea, from an implementation standpoint it would
probably be a headache to maintain.


> alex

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message