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. 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/
