Hi all , My GSoC proposal got accepted.So i would like to thanks you all for the support and ideas you gave. I have start working on a patch for the in memory message store.Personally i prefer to do this project in an iterative way so that i can provide patches and it will get reviewed and get apply to the tunk time to time.
I'll be glad to get your feedbacks while doing the project. thanks, /Charith On Wed, Apr 7, 2010 at 2:32 PM, Charith Wickramarachchi < [email protected]> wrote: > I submited the Proposal in the Google OpenSource Program WebSite > > Following are the links to Proposal in Google Space and Apache Wiki Space > > > > http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/charith/t127030145826<http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/charith/t127030145826> > > > http://wiki.apache.org/general/charith/gsoc2010/synapse_deadLetter > > thanks, > Charith > > On Fri, Apr 2, 2010 at 2:28 PM, Charith Wickramarachchi < > [email protected]> wrote: > >> 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/ >> >> > > > -- > Charith Dhanushka Wickramarachchi > http://charithwiki.blogspot.com/ > > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
