On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi < [email protected]> wrote:
> 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> > Charith, formatting of the document seems to be messed up a little bit. Please have a look. Also once you are done, shall we bring this into the Apache Wiki. I'd like to have everything related to this project in the ASF space. Thanks, Hiranya > > 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/ > > -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
