Hi, I wrote draft Proposal for the Project and its available at [1] <http://socghop.appspot.com/document/show/user/charith/deadletterchannel_synapse> your feed backs on changes or improvements to the proposal is highly appreciated.
[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/
