I add the project proposal to the Apache Wiki space.http://wiki.apache.org/general/charith/gsoc2010/synapse_deadLetter
thanks, Charith On Fri, Apr 2, 2010 at 12:20 AM, Charith Wickramarachchi < [email protected]> wrote: > > > On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <[email protected] > > wrote: > >> >> >> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi < >> [email protected]> wrote: >> >>> Thanks you for your feed back. >>> >>> I updated it with the changes you proposed.You can find the new document >>> here >>> [1]<http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse> >>> >> >> Charith, formatting of the document seems to be messed up a little bit. >> > > Yes. i 'm having a issue with google docs provided in the Summer of code > site. > google > >> Please have a look. Also once you are done, shall we bring this into the >> Apache Wiki. I'd like to have everything related to this >> > project in the ASF space. >> Sure.I'll put new proposal in a Apache Wiki Space. >> > > /charith > > >> Thanks, >> Hiranya >> >> >>> >>> thanks, >>> Charith >>> >>> [1 >>> ]http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse >>> >>> <http://socghop.appspot.com/document/show/user/charith/deadletterchannel_apache_synapse> >>> >>> On Sun, Mar 28, 2010 at 10:32 AM, Hiranya Jayathilaka < >>> [email protected]> wrote: >>> >>>> 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] >>>> >>>> >>> >>> >>> -- >>> 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 >> > > > > -- > Charith Dhanushka Wickramarachchi > http://charithwiki.blogspot.com/ > > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
