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/
