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]
