Hi Charith, 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].
Thanks for looking into this. > > 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. +1 To start with we can have a simple default redelivery policy (or a couple of them to choose from). Ability to turn off redelivery is required as well. In the long run we should be able to use something like WS-Policy to specify redelivery requirements. But that's something for the future. I think you can keep it out of your project scope for now. However keep room for improvement and extension in your design. Also right now you should think about the type of metadata you are going to store in the message store along with each message. We should store some data about each message that will help us in the redelivery process. I think the target EPR of the message is a must. Think about the other stuff we need to hold on to as well. > > 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. This shouldn't be a problem. The message store configuration can refer to an existing sequence or can define an in-line sequence to support this requirement. <messageStore class="my.class.Name" notifySequence="my.sequence"/> We can bridge this nicely with our event source implementation to send out WS-Eventing notifications too. > > 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. I think there is an easier approach. We just need to introduce an interface for the message store concept. All message store implementations must implement it, and the message store configuration should point to an implementation by its full qualified class name. That should solve this problem. Have a look at how Synapse tasks and class mediator works. I think the priority executor concept that was added by Supun recently also does something similar. Thanks, Hiranya > > 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/ > > -- 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]
