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/
