Thanks you for your feed back. I updated it with the changes you proposed.You can find the new document here [1]<http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse>
thanks, Charith [1 ]http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse <http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse> On Sun, Mar 28, 2010 at 10:32 AM, Hiranya Jayathilaka <[email protected]>wrote: > Hi Charith, > > On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi > <[email protected]> wrote: > > Hi, > > > > I wrote draft Proposal for the Project and its available at [1] > > your feed backs on changes or improvements to the proposal is highly > > appreciated. > > I had a quick look at the proposal. Pretty good stuff. I would also > like to see a sample message store configuration in the document along > with an endpoint configuration which uses the message store. Also I > believe you can include the mediator development (currently listed > under optional features) in the second development phase. I don't > think writing a mediator takes that much time. > > Also please cite the source of your diagram ;) > > Thanks, > Hiranya > > > > > [1] > http://socghop.appspot.com/document/show/user/charith/deadletterchannel_synapse > > > > On Wed, Mar 24, 2010 at 10:40 AM, Charith Wickramarachchi > > <[email protected]> wrote: > >> > >> Thank you all for your feedbacks. > >> > >> I'm currently looking at the Synapse Fault Handling Mechanism to Find a > >> way to implement this. > >> As far as i understand synapse uses a Stack base Fault handling > Mechanism > >> to achieve fault handling > >> at the different Levels of the Sequences and Endpoints in a correct > >> order. > >> > >> I'm having some questions now. > >> > >> Implementing this with the Endpoint fault handling is clear to me.Where > we > >> can put the redelivery parameters/policies and Message Store at the end > >> point so that at a failure it will considerer that parameters before > >> executing the fault handler (so it will try to re deliver it according > to > >> the parameters /policy s specified and if failed it will store the > Message > >> ). As Amila said there we can use WS-RM policies. > >> > >> Do we need to impliment this with the Sequences too ? > >> > >> Then we need to have a machansim to find how to determine the sequnce > name > >> and at which level this message has failed from the stored Meta data > (Since > >> same sequnces can be re used at deffrent levels). > >> > >> my next Question is about Stroing the Message? > >> > >> Since idea if storing the message is to be able to re generate the same > >> message again. Are we going to store the MessageContext object ? (And in > a > >> persistent storage case we can use a Adapter and serialise that > object.)Or > >> is there a better memory effcient way? > >> > >> WDYT? > >> > >> > >> > >> > >> On Mon, Mar 22, 2010 at 10:57 AM, Amila Suriarachchi > >> <[email protected]> wrote: > >>> > >>> > >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi > >>> <[email protected]> wrote: > >>>> > >>>> Hi, > >>>> > >>>> Thanks for the reply and your feed back. I looked in to the Apache > Camel > >>>> DeadLetter channel features and its uses. > >>>> And also FUSE Mediation Router support this EIP too.[1]. > >>>> > >>>> As per my current understanding Re delivery policies plays a major > role > >>>> when supporting this Pattern.Where users can configure the re delivery > >>>> policy so that system will retry to deliver before message added to > the > >>>> Message store according to the policy defined. > >>> > >>> one option is to use ws-rm. which gives you a standard mechanism of > >>> handling retransmissions. > >>> > >>> thanks, > >>> Amila. > >>>> > >>>> And also i found that there is a requirement to make enable to execute > a > >>>> sequence after message is added to the message store(or just before > adding > >>>> to Message Store). > >>>> So that it can be used to send notifications to the pre configured > >>>> persons telling that Messages has been added to the Message store/Dead > >>>> letter channel. > >>>> > >>>> I'm currently looking in to the Synapse code and architecture to > figure > >>>> out ways of implementing this.So your feed back is highly appreciated. > >>>> > >>>> As i understand synapse Currenty has a mechanism to plug custom > >>>> configuration elements. > >>>> ConfigurationFactoryAndSerializerFinder does that. So it looks like > that > >>>> the requirement Hiranya Mentioned about beging able to plug custom > Message > >>>> Stores easily can be archived using that Service provider machanishm. > >>>> > >>>> Your ideas on better ways of implimenting this feature is highly > >>>> appriciated. > >>>> > >>>> thanks, > >>>> /Charith > >>>> > >>>> > >>>> [1]http://fusesource.com/docs/router/1.6/eip/MsgCh-DeadLetter.html > >>>> > >>>> > >>>> > >>>> On Thu, Mar 18, 2010 at 9:09 PM, Hiranya Jayathilaka > >>>> <[email protected]> wrote: > >>>>> > >>>>> Hi Charith, > >>>>> > >>>>> There are actually several ways we can tackle this problem. And right > >>>>> now even I'm not sure which approach is the best. We need to discuss > >>>>> the options we got and then get to a suitable and feasible solution. > >>>>> > >>>>> One solution is to introduce a new top level component (as you have > >>>>> suggested) for the message stores. The sequences already have the > >>>>> onError attribute which can be used to specify a custom fault > sequence > >>>>> to be executed in case of an error. If a custom fault sequence is not > >>>>> specified the default fault sequence will take over the control. > Proxy > >>>>> services also have the concept of fault sequences. So we need to > >>>>> figure out how to link up this concept of fault sequences with the > >>>>> message store top level element. One option would be to write a > >>>>> mediator which can be placed in a fault sequence. The mediator will > >>>>> take the faulty message and place it in a specified message store. > >>>>> > >>>>> On the other hand we can just have the mediator. The message store > >>>>> concept can be built into the mediator itself so we don't need a new > >>>>> top level element. This approach however has the disadvantage of not > >>>>> being able to share and reuse a single message store instance across > >>>>> the Synapse configuration. > >>>>> > >>>>> Another possible approach is to have the message store top level > >>>>> element and then introduce an onError attribute to the endpoint top > >>>>> level element. This is the approach suggested by Ruwan at [1]. > >>>>> > >>>>> Please consider all these options when working on your proposal. Also > >>>>> please take a look at some existing implementations of the dead > letter > >>>>> channel pattern. FYI Apache Camel supports this pattern.If we can > >>>>> reuse some of the stuff done in Camel that would be fine too. > >>>>> Personally though I prefer having our native implementation of the > >>>>> dead letter channel pattern. And to be frank I does like the idea of > >>>>> having the message store as a top level element in Synapse. > >>>>> > >>>>> I'm sure other members of the team also have a lot of ideas with > >>>>> regard to this project. Let's give them sometime and see what they > >>>>> think too :) > >>>>> > >>>>> Thanks, > >>>>> Hiranya > >>>>> > >>>>> [1] - https://issues.apache.org/jira/browse/SYNAPSE-263 > >>>>> > >>>>> > >>>>> On Thu, Mar 18, 2010 at 12:36 PM, Charith Wickramarachchi > >>>>> <[email protected]> wrote: > >>>>> > Hi Hiranya, > >>>>> > > >>>>> > This I went through idea you mention in the proposal. > >>>>> > > >>>>> > This is the picture of the High level design in my mind after > looking > >>>>> > into > >>>>> > it. > >>>>> > The Message Store will be a high level synapse configuration > >>>>> > construct (at > >>>>> > the sequence , endpoint ... )level. > >>>>> > > >>>>> > > >>>>> > Ex > >>>>> > <msg_store name ="foo" class = > >>>>> > "org.apache.synapse.core.JDBCMessageStore" > >>>>> > .....> > >>>>> > Other message store specific details goes here ex : scheduling > >>>>> > info , > >>>>> > user names , urls > >>>>> > </msg_store> > >>>>> > > >>>>> > and sequences and the endpoints must be able to point to this store > >>>>> > with a > >>>>> > parameter like "on fault" > >>>>> > and also there can be multiple message stores that can be reused. > >>>>> > > >>>>> > Is this the idea in your mind? > >>>>> > > >>>>> > WDYT? your feed back will be highly appreciated so that i can > improve > >>>>> > my > >>>>> > proposal. > >>>>> > > >>>>> > thank, > >>>>> > /Charith > >>>>> > > >>>>> > On Thu, Mar 18, 2010 at 12:03 PM, Charith Wickramarachchi > >>>>> > <[email protected]> wrote: > >>>>> >> > >>>>> >> Hi, > >>>>> >> > >>>>> >> I m a Undergraduate Interested in this Project idea. I have worked > >>>>> >> with > >>>>> >> the synapse code base So i 'm glad to do this project as my GSoC > >>>>> >> project. > >>>>> >> > >>>>> >> I'm now looking in to the ways of designing and implementing > this.I > >>>>> >> m > >>>>> >> willing to have more design level ideas regarding this. > >>>>> >> > >>>>> >> I'll come up with a proposal for this soon. > >>>>> >> > >>>>> >> thanks, > >>>>> >> > >>>>> >> Charith > >>>>> >> > >>>>> >> On Wed, Mar 17, 2010 at 5:20 PM, Hiranya Jayathilaka (JIRA) > >>>>> >> <[email protected]> wrote: > >>>>> >>> > >>>>> >>> [GSoC] Implement a Dead Letter Channel for Synapse > >>>>> >>> -------------------------------------------------- > >>>>> >>> > >>>>> >>> Key: SYNAPSE-618 > >>>>> >>> URL: > >>>>> >>> https://issues.apache.org/jira/browse/SYNAPSE-618 > >>>>> >>> Project: Synapse > >>>>> >>> Issue Type: New Feature > >>>>> >>> Components: Core, Endpoints > >>>>> >>> Reporter: Hiranya Jayathilaka > >>>>> >>> Fix For: FUTURE > >>>>> >>> > >>>>> >>> > >>>>> >>> Currently when Synapse attempts to send a message and if it > fails, > >>>>> >>> following actions can be configured to deal with the error: > >>>>> >>> > >>>>> >>> * Execute a fault sequence and handle the failed request > gracefully > >>>>> >>> * Fail-over to a different endpoint > >>>>> >>> > >>>>> >>> In addition to these, Synapse ESB should support the "dead letter > >>>>> >>> channel" enterprise integration pattern to deal with various > errors > >>>>> >>> that > >>>>> >>> might occur during mediation or while sending. With the dead > letter > >>>>> >>> channel, > >>>>> >>> the failed message will be put into a message store in the ESB. > >>>>> >>> Later the > >>>>> >>> ESB can retry to send the messages in the message store. > >>>>> >>> > >>>>> >>> We should be able to have multiple implementations of the actual > >>>>> >>> message > >>>>> >>> store and should be able to configure which store to use for a > >>>>> >>> particular > >>>>> >>> scenario. Users should be able to implement their own message > >>>>> >>> stores and > >>>>> >>> plug into the ESB easily. To start with we can have a simple > >>>>> >>> in-memory > >>>>> >>> message store and a persisting store based on JDBC or JMS. > >>>>> >>> > >>>>> >>> References: > >>>>> >>> http://www.eaipatterns.com/DeadLetterChannel.html > >>>>> >>> https://issues.apache.org/jira/browse/SYNAPSE-263 > >>>>> >>> > >>>>> >>> Possible Mentors: > >>>>> >>> Hiranya Jayathilaka > >>>>> >>> > >>>>> >>> > >>>>> >>> -- > >>>>> >>> This message is automatically generated by JIRA. > >>>>> >>> - > >>>>> >>> You can reply to this email to add a comment to the issue online. > >>>>> >>> > >>>>> >>> > >>>>> >>> > >>>>> >>> > --------------------------------------------------------------------- > >>>>> >>> To unsubscribe, e-mail: [email protected] > >>>>> >>> For additional commands, e-mail: [email protected] > >>>>> >>> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> -- > >>>>> >> Charith Dhanushka Wickramarachchi > >>>>> >> http://charithwiki.blogspot.com/ > >>>>> >> > >>>>> > > >>>>> > > >>>>> > > >>>>> > -- > >>>>> > Charith Dhanushka Wickramarachchi > >>>>> > http://charithwiki.blogspot.com/ > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Hiranya Jayathilaka > >>>>> Software Engineer; > >>>>> WSO2 Inc.; http://wso2.org > >>>>> E-mail: [email protected]; Mobile: +94 77 633 3491 > >>>>> Blog: http://techfeast-hiranya.blogspot.com > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Charith Dhanushka Wickramarachchi > >>>> http://charithwiki.blogspot.com/ > >>>> > >>> > >>> > >>> > >>> -- > >>> Amila Suriarachchi > >>> WSO2 Inc. > >>> blog: http://amilachinthaka.blogspot.com/ > >> > >> > >> > >> -- > >> Charith Dhanushka Wickramarachchi > >> http://charithwiki.blogspot.com/ > >> > > > > > > > > -- > > Charith Dhanushka Wickramarachchi > > http://charithwiki.blogspot.com/ > > > > > > > > -- > Hiranya Jayathilaka > Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
