On Thu, Aug 6, 2009 at 8:12 PM, Douglas Leite <[email protected]> wrote:
> The last updates in my project are related to allowing the existence of > concurrent exceptions, as well as providing suitable mechanisms to treat > them ([1]). The sequence diagram at [2] shows the messages exchange between > the guardian group, guardian members, and participants, when a participant > raises an external exception. > > First of all, the participant that wants to raise an external exception, > invokes the *gthrow* method from its respective guardian member. The > exception is propagated to the guardian group that set all the involved > participants in a suspended state. A participant can assume two states: > normal and suspended. When a participant is suspended, it blocks until its > state change to the normal state. (However, in the current implementation > the participants that did not raise an external exception, continue its > normal execution, in a normal state, until an exception is raised in it). > > After that, the guardian group starts a new thread to process the external > exception. The process consists in applying the recovery rules that was > defined by the programmer (see an example at [3]). The recovery rules define > which exception should be raised in a specific participant (or a set of > participants) when an external exception is signaled from a participant to > the guardian. > > While an exception is being processed, another exception may be raised by > other participant, in other words, concurrent exceptions may occur. The > concurrent exceptions are queued in the guardian group, and before applying > the solution described at the recovery rules for the first exception raised, > the guardian checks if there are, or not, concurrent exceptions queued. > > In case of concurrent exceptions, the guardian provides the list of all > concurrent exceptions to the concurrent recovery rules. These ones check for > the lowest common ancestor (LCA) of all the concurrent exceptions in a > resolution tree (see an example at [4]). If there is a LCA, then the > guardian invokes the recovery rules for this exception. Otherwise, the > guardian simple invokes the recovery rules for each concurrent exception > sequentially. > > In the end, the resolved exception is delivered to the guardian members, > and raised in its respective participants by the invocation of the * > checkStatusException* method. > > There are some things related to the design and algorithms that I need to > review in order to enhance the model. Despite of that, all the parts of the > model were already implemented. > > Some possible next stpes are: > > 1) Use the recovery rules and resolution tree as policies; > 2) Test the examples with remotable interface; > 3) Use implicit declaration of the guardian members; > > Thoughts? > > [1] > http://svn.apache.org/repos/asf/tuscany/sandbox/dougsleite/guardian-model/ > [2] > http://svn.apache.org/repos/asf/tuscany/sandbox/dougsleite/guardian-model/sequenceDiagram-externalException.jpg > [3] > http://svn.apache.org/repos/asf/tuscany/sandbox/dougsleite/guardian-model/src/main/resources/recoveryrules_nbackpus.xml > [4] > http://svn.apache.org/repos/asf/tuscany/sandbox/dougsleite/guardian-model/src/main/resources/resolutionTree.xml > > -- > Douglas Siqueira Leite > Graduate student at University of Campinas (Unicamp), Brazil > > Hi Douglas, At this point of time, is it currently possible to integrate the code you have developed so far with Tuscany and test the same. I understand that, you are planning for some improvements like declaring the recovery rules as policies, apart from these improvements what is the status on the core model and how does it work with Tuscany. More details on how things would work with respect to Tuscany module would help the community to evaluate your solution better. -- Thanks & Regards, Ramkumar Ramalingam
