Hi Charith,
On Tue, Apr 27, 2010 at 12:04 PM, Charith Wickramarachchi < [email protected]> wrote: > Hi all , > > My GSoC proposal got accepted. Congratulations. Looking forward to work with you in the next few months to come. > 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. > It's great you have already started working on this. Please feel free to write to the list or contact me personally if you need any assistance. Also please keep the list informed about your progress by sending weekly updates. It would be even better if you can maintain a wiki page as a journal with regular updates. Thanks, Hiranya > 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/ > > -- Hiranya Jayathilaka Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
