You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Hiranya Jayathilaka (JIRA)" <ji...@apache.org> on 2010/03/17 12:50:27 UTC
[jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
[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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Charith,
On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
<ch...@gmail.com> 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].
Thanks for looking into this.
>
> 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.
+1
To start with we can have a simple default redelivery policy (or a
couple of them to choose from). Ability to turn off redelivery is
required as well. In the long run we should be able to use something
like WS-Policy to specify redelivery requirements. But that's
something for the future. I think you can keep it out of your project
scope for now. However keep room for improvement and extension in your
design.
Also right now you should think about the type of metadata you are
going to store in the message store along with each message. We should
store some data about each message that will help us in the redelivery
process. I think the target EPR of the message is a must. Think about
the other stuff we need to hold on to as well.
>
> 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.
This shouldn't be a problem. The message store configuration can refer
to an existing sequence or can define an in-line sequence to support
this requirement.
<messageStore class="my.class.Name" notifySequence="my.sequence"/>
We can bridge this nicely with our event source implementation to send
out WS-Eventing notifications too.
>
> 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.
I think there is an easier approach. We just need to introduce an
interface for the message store concept. All message store
implementations must implement it, and the message store configuration
should point to an implementation by its full qualified class name.
That should solve this problem. Have a look at how Synapse tasks and
class mediator works. I think the priority executor concept that was
added by Supun recently also does something similar.
Thanks,
Hiranya
>
> 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 <hi...@gmail.com>
> 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
>> <ch...@gmail.com> 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
>> > <ch...@gmail.com> 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)
>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> Blog: http://techfeast-hiranya.blogspot.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
--
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Tue, Apr 27, 2010 at 2:43 PM, Ruwan Linton <ru...@gmail.com>wrote:
> Congratulations!
>
> +1 for the iterative development approach.
>
> BTW: you could also contribute to the synapse 2.0 release ;-)
> Sure I'm glad to do some fixs
>
> Thanks,
> Ruwan
>
>
> On Tue, Apr 27, 2010 at 12:04 PM, Charith Wickramarachchi <
> charith.dhanushka@gmail.com> wrote:
>
>> 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 <
>> charith.dhanushka@gmail.com> 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 <
>>> charith.dhanushka@gmail.com> 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 <
>>>> charith.dhanushka@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <
>>>>> hiranya911@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
>>>>>> charith.dhanushka@gmail.com> 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 <
>>>>>>> hiranya911@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Charith,
>>>>>>>>
>>>>>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>>>>>>> <ch...@gmail.com> 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
>>>>>>>> > <ch...@gmail.com> 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
>>>>>>>> >> <am...@gmail.com> wrote:
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>>>>>>> >>> <ch...@gmail.com> 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
>>>>>>>> >>>> <hi...@gmail.com> 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
>>>>>>>> >>>>> <ch...@gmail.com> 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
>>>>>>>> >>>>> > <ch...@gmail.com> 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)
>>>>>>>> >>>>> >> <ji...@apache.org> 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:
>>>>>>>> dev-unsubscribe@synapse.apache.org
>>>>>>>> >>>>> >>> For additional commands, e-mail:
>>>>>>>> dev-help@synapse.apache.org
>>>>>>>> >>>>> >>>
>>>>>>>> >>>>> >>
>>>>>>>> >>>>> >>
>>>>>>>> >>>>> >>
>>>>>>>> >>>>> >> --
>>>>>>>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>> >>>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> --
>>>>>>>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Charith Dhanushka Wickramarachchi
>>>>>>> http://charithwiki.blogspot.com/
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Hiranya Jayathilaka
>>>>>> Software Engineer;
>>>>>> WSO2 Inc.; http://wso2.org
>>>>>> E-mail: hiranya@wso2.com; 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/
>>
>>
>
>
> --
> Ruwan Linton
> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
> WSO2 Inc.; http://wso2.org
> email: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Ruwan Linton <ru...@gmail.com>.
Congratulations!
+1 for the iterative development approach.
BTW: you could also contribute to the synapse 2.0 release ;-)
Thanks,
Ruwan
On Tue, Apr 27, 2010 at 12:04 PM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> wrote:
> 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 <
> charith.dhanushka@gmail.com> 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 <
>> charith.dhanushka@gmail.com> 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 <
>>> charith.dhanushka@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <
>>>> hiranya911@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
>>>>> charith.dhanushka@gmail.com> 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 <
>>>>>> hiranya911@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Charith,
>>>>>>>
>>>>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>>>>>> <ch...@gmail.com> 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
>>>>>>> > <ch...@gmail.com> 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
>>>>>>> >> <am...@gmail.com> wrote:
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>>>>>> >>> <ch...@gmail.com> 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
>>>>>>> >>>> <hi...@gmail.com> 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
>>>>>>> >>>>> <ch...@gmail.com> 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
>>>>>>> >>>>> > <ch...@gmail.com> 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)
>>>>>>> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>>>>> >>>>> >>> For additional commands, e-mail:
>>>>>>> dev-help@synapse.apache.org
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>
>>>>>>> >>>>> >>
>>>>>>> >>>>> >>
>>>>>>> >>>>> >> --
>>>>>>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> --
>>>>>>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Charith Dhanushka Wickramarachchi
>>>>>> http://charithwiki.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hiranya Jayathilaka
>>>>> Software Engineer;
>>>>> WSO2 Inc.; http://wso2.org
>>>>> E-mail: hiranya@wso2.com; 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/
>
>
--
Ruwan Linton
Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Charith,
On Tue, Apr 27, 2010 at 12:04 PM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> 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 <
> charith.dhanushka@gmail.com> 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 <
>> charith.dhanushka@gmail.com> 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 <
>>> charith.dhanushka@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <
>>>> hiranya911@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
>>>>> charith.dhanushka@gmail.com> 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 <
>>>>>> hiranya911@gmail.com> wrote:
>>>>>>
>>>>>>> Hi Charith,
>>>>>>>
>>>>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>>>>>> <ch...@gmail.com> 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
>>>>>>> > <ch...@gmail.com> 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
>>>>>>> >> <am...@gmail.com> wrote:
>>>>>>> >>>
>>>>>>> >>>
>>>>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>>>>>> >>> <ch...@gmail.com> 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
>>>>>>> >>>> <hi...@gmail.com> 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
>>>>>>> >>>>> <ch...@gmail.com> 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
>>>>>>> >>>>> > <ch...@gmail.com> 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)
>>>>>>> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>>>>> >>>>> >>> For additional commands, e-mail:
>>>>>>> dev-help@synapse.apache.org
>>>>>>> >>>>> >>>
>>>>>>> >>>>> >>
>>>>>>> >>>>> >>
>>>>>>> >>>>> >>
>>>>>>> >>>>> >> --
>>>>>>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> --
>>>>>>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Charith Dhanushka Wickramarachchi
>>>>>> http://charithwiki.blogspot.com/
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Hiranya Jayathilaka
>>>>> Software Engineer;
>>>>> WSO2 Inc.; http://wso2.org
>>>>> E-mail: hiranya@wso2.com; 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: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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 <
charith.dhanushka@gmail.com> 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 <
> charith.dhanushka@gmail.com> 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 <
>> charith.dhanushka@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <
>>> hiranya911@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
>>>> charith.dhanushka@gmail.com> 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 <
>>>>> hiranya911@gmail.com> wrote:
>>>>>
>>>>>> Hi Charith,
>>>>>>
>>>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>>>>> <ch...@gmail.com> 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
>>>>>> > <ch...@gmail.com> 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
>>>>>> >> <am...@gmail.com> wrote:
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>>>>> >>> <ch...@gmail.com> 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
>>>>>> >>>> <hi...@gmail.com> 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
>>>>>> >>>>> <ch...@gmail.com> 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
>>>>>> >>>>> > <ch...@gmail.com> 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)
>>>>>> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>>>> >>>>> >>> For additional commands, e-mail:
>>>>>> dev-help@synapse.apache.org
>>>>>> >>>>> >>>
>>>>>> >>>>> >>
>>>>>> >>>>> >>
>>>>>> >>>>> >>
>>>>>> >>>>> >> --
>>>>>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> --
>>>>>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Charith Dhanushka Wickramarachchi
>>>>> http://charithwiki.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Hiranya Jayathilaka
>>>> Software Engineer;
>>>> WSO2 Inc.; http://wso2.org
>>>> E-mail: hiranya@wso2.com; 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/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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 <
charith.dhanushka@gmail.com> 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 <
> charith.dhanushka@gmail.com> wrote:
>
>>
>>
>> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <
>> hiranya911@gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
>>> charith.dhanushka@gmail.com> 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 <
>>>> hiranya911@gmail.com> wrote:
>>>>
>>>>> Hi Charith,
>>>>>
>>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>>>> <ch...@gmail.com> 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
>>>>> > <ch...@gmail.com> 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
>>>>> >> <am...@gmail.com> wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>>>> >>> <ch...@gmail.com> 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
>>>>> >>>> <hi...@gmail.com> 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
>>>>> >>>>> <ch...@gmail.com> 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
>>>>> >>>>> > <ch...@gmail.com> 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)
>>>>> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>>> >>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>>>> >>>
>>>>> >>>>> >>
>>>>> >>>>> >>
>>>>> >>>>> >>
>>>>> >>>>> >> --
>>>>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>> >>>>>
>>>>> >>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> --
>>>>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Charith Dhanushka Wickramarachchi
>>>> http://charithwiki.blogspot.com/
>>>>
>>>>
>>>
>>>
>>> --
>>> Hiranya Jayathilaka
>>> Software Engineer;
>>> WSO2 Inc.; http://wso2.org
>>> E-mail: hiranya@wso2.com; 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/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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 <
charith.dhanushka@gmail.com> wrote:
>
>
> On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka <hiranya911@gmail.com
> > wrote:
>
>>
>>
>> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
>> charith.dhanushka@gmail.com> 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 <
>>> hiranya911@gmail.com> wrote:
>>>
>>>> Hi Charith,
>>>>
>>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>>> <ch...@gmail.com> 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
>>>> > <ch...@gmail.com> 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
>>>> >> <am...@gmail.com> wrote:
>>>> >>>
>>>> >>>
>>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>>> >>> <ch...@gmail.com> 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
>>>> >>>> <hi...@gmail.com> 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
>>>> >>>>> <ch...@gmail.com> 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
>>>> >>>>> > <ch...@gmail.com> 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)
>>>> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>> >>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>> >>>>> >>>
>>>> >>>>> >>
>>>> >>>>> >>
>>>> >>>>> >>
>>>> >>>>> >> --
>>>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>> >>>>>
>>>> >>>>>
>>>> ---------------------------------------------------------------------
>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> --
>>>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Charith Dhanushka Wickramarachchi
>>> http://charithwiki.blogspot.com/
>>>
>>>
>>
>>
>> --
>> Hiranya Jayathilaka
>> Software Engineer;
>> WSO2 Inc.; http://wso2.org
>> E-mail: hiranya@wso2.com; 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/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
On Thu, Apr 1, 2010 at 10:50 AM, Hiranya Jayathilaka
<hi...@gmail.com>wrote:
>
>
> On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
> charith.dhanushka@gmail.com> 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 <
>> hiranya911@gmail.com> wrote:
>>
>>> Hi Charith,
>>>
>>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>>> <ch...@gmail.com> 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
>>> > <ch...@gmail.com> 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
>>> >> <am...@gmail.com> wrote:
>>> >>>
>>> >>>
>>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>> >>> <ch...@gmail.com> 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
>>> >>>> <hi...@gmail.com> 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
>>> >>>>> <ch...@gmail.com> 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
>>> >>>>> > <ch...@gmail.com> 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)
>>> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>> >>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>> >>>>> >>>
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >>
>>> >>>>> >> --
>>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>>> >>>>>
>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>> Blog: http://techfeast-hiranya.blogspot.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>>
>
>
> --
> Hiranya Jayathilaka
> Software Engineer;
> WSO2 Inc.; http://wso2.org
> E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Sun, Mar 28, 2010 at 1:25 PM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> 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.
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.
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 <
> hiranya911@gmail.com> wrote:
>
>> Hi Charith,
>>
>> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
>> <ch...@gmail.com> 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
>> > <ch...@gmail.com> 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
>> >> <am...@gmail.com> wrote:
>> >>>
>> >>>
>> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>> >>> <ch...@gmail.com> 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
>> >>>> <hi...@gmail.com> 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
>> >>>>> <ch...@gmail.com> 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
>> >>>>> > <ch...@gmail.com> 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)
>> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>> >>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>>>> >>>
>> >>>>> >>
>> >>>>> >>
>> >>>>> >>
>> >>>>> >> --
>> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> >>>>> Blog: http://techfeast-hiranya.blogspot.com
>> >>>>>
>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> Blog: http://techfeast-hiranya.blogspot.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
--
Hiranya Jayathilaka
Software Engineer;
WSO2 Inc.; http://wso2.org
E-mail: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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>
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
<hi...@gmail.com>wrote:
> Hi Charith,
>
> On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
> <ch...@gmail.com> 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
> > <ch...@gmail.com> 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
> >> <am...@gmail.com> wrote:
> >>>
> >>>
> >>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
> >>> <ch...@gmail.com> 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
> >>>> <hi...@gmail.com> 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
> >>>>> <ch...@gmail.com> 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
> >>>>> > <ch...@gmail.com> 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)
> >>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
> >>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
> >>>>> >>>
> >>>>> >>
> >>>>> >>
> >>>>> >>
> >>>>> >> --
> >>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
> >>>>> Blog: http://techfeast-hiranya.blogspot.com
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> >>>>> For additional commands, e-mail: dev-help@synapse.apache.org
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
Hi Charith,
On Sat, Mar 27, 2010 at 2:35 PM, Charith Wickramarachchi
<ch...@gmail.com> 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
> <ch...@gmail.com> 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
>> <am...@gmail.com> wrote:
>>>
>>>
>>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi
>>> <ch...@gmail.com> 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
>>>> <hi...@gmail.com> 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
>>>>> <ch...@gmail.com> 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
>>>>> > <ch...@gmail.com> 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)
>>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
Hi,
I wrote draft Proposal for the Project and its available at [1]
<http://socghop.appspot.com/document/show/user/charith/deadletterchannel_synapse>
your feed backs on changes or improvements to the proposal is highly
appreciated.
[1]
http://socghop.appspot.com/document/show/user/charith/deadletterchannel_synapse
On Wed, Mar 24, 2010 at 10:40 AM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> 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 <
> amilasuriarachchi@gmail.com> wrote:
>
>>
>>
>> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi <
>> charith.dhanushka@gmail.com> 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 <
>>> hiranya911@gmail.com> 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
>>>> <ch...@gmail.com> 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
>>>> > <ch...@gmail.com> 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)
>>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>>> Blog: http://techfeast-hiranya.blogspot.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> 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/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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 <
amilasuriarachchi@gmail.com> wrote:
>
>
> On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi <
> charith.dhanushka@gmail.com> 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 <
>> hiranya911@gmail.com> 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
>>> <ch...@gmail.com> 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
>>> > <ch...@gmail.com> 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)
>>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>>> Blog: http://techfeast-hiranya.blogspot.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>>
>>
>>
>> --
>> Charith Dhanushka Wickramarachchi
>> http://charithwiki.blogspot.com/
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Amila Suriarachchi <am...@gmail.com>.
On Sat, Mar 20, 2010 at 9:29 PM, Charith Wickramarachchi <
charith.dhanushka@gmail.com> 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 <hiranya911@gmail.com
> > 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
>> <ch...@gmail.com> 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
>> > <ch...@gmail.com> 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)
>> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>> >>> For additional commands, e-mail: dev-help@synapse.apache.org
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
>> Blog: http://techfeast-hiranya.blogspot.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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.
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
<hi...@gmail.com>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
> <ch...@gmail.com> 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
> > <ch...@gmail.com> 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)
> >> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
> >>> For additional commands, e-mail: dev-help@synapse.apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
> Blog: http://techfeast-hiranya.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
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
<ch...@gmail.com> 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
> <ch...@gmail.com> 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)
>> <ji...@apache.org> 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: dev-unsubscribe@synapse.apache.org
>>> For additional commands, e-mail: dev-help@synapse.apache.org
>>>
>>
>>
>>
>> --
>> 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: hiranya@wso2.com; Mobile: +94 77 633 3491
Blog: http://techfeast-hiranya.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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 <
charith.dhanushka@gmail.com> 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) <
> jira@apache.org> 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: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>>
>
>
> --
> Charith Dhanushka Wickramarachchi
> http://charithwiki.blogspot.com/
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by Charith Wickramarachchi <ch...@gmail.com>.
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) <jira@apache.org
> 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: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Charith Dhanushka Wickramarachchi
http://charithwiki.blogspot.com/
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846741#action_12846741 ]
Asankha C. Perera commented on SYNAPSE-618:
-------------------------------------------
Hi Denis
> Regarding [1] , My mentor Milinda Pathirage on ODE-565 redirected Marco to me and he started to personally contact me,..
There seems to be many issues here..
1) I do not see anyone requiring redirection, as Marco asked a question on the public mailing list - to which no one has replied yet, when anyone could have replied - even directing Marco to you, publicly
2) Open source projects means that community interaction is also open, so whoever wanted to improve your code could have discussed issues openly - on the mailing list/JIRA
3) Then, if another person made changes to code, you legally *cannot* attach such code as "yours" as it is seen in the above JIRA today. This is why the ASF requires each contributor to specifically grant the ASF the authority to use the code when you upload a patch to a JIRA - so now it seems like the ASF has been entangled into a legal issue as well by your hurried act - and I suggest you remove this attachment.
More seriously, I do not think you met the objective of the GSoc project [my earlier link], when you clearly stopped participation in the ODE project soon after the GSoc stuff was in a state of submission for you after just a couple of months. I also see that your completion status was not included into the ASF board report [1] after reminders - though its not your fault
Leaving all these aside, you were always free to contribute to Synapse anytime. And I believe GSoc as per its objective "inspired" you to "begin" participating in open source projects. After completing one round with GSoc, showing spontaneous enthusiasm in this Synapse JIRA just approximately 7 hrs after being published, but forgetting the ODE project where your involvement was funded by GSoc earlier seems to indicate possibly something else.. I personally believed the GSoc program was to just "bring in" students into open source, and that doing it once is enough. I do not have any questions on the technical aspects of what you had done, or plan to do now, but about what really motivates you..
asankha
[1] http://markmail.org/message/ipc7dzjm532nw3ia
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: synapse_sample_1.xml
messagestore_patch_1.diff
This is the 1st patch for the Dead letter channel EIP implementation.
This adds a in memory message store with a simple redelivery processor.
Message store is currently associated with endpoints.
This implemention will be improved with time as discussed in
http://wiki.apache.org/general/charith/gsoc2010/synapse_deadLetter
http://markmail.org/message/4lji7luz37k5xsv3?q=Synapse+Message+Store
please review and commit
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Hiranya Jayathilaka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872851#action_12872851 ]
Hiranya Jayathilaka commented on SYNAPSE-618:
---------------------------------------------
Hi Charith,
Good job. I'll go through the patch and get back to you with some feedback.
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_7.diff
Added improvements to the current Persistence Message store
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846731#action_12846731 ]
Asankha C. Perera commented on SYNAPSE-618:
-------------------------------------------
Denis
I found https://issues.apache.org/jira/browse/ODE-565 from the ODE project where you've attached about 5MB of changes from late Mar to early Sep 2009, but unfortunately that's not checked into ODE, nor does any review comments or interaction from the community present against it..
Your emails in the ODE dev list stopped in Sep 2009, and you've failed to reply another student who wanted to use your code in Dec 2009 [1] for his research
Do you think this project met the objectives of Google [2] who funded it?
asankha
[1] http://markmail.org/message/7oxz6asa7tu5dlwu
[2] http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#goals
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_3.diff
synapse_sample_1.xml
Added the JMX view for the Message Store
getSize() :int //give the current Message store size
resendAll() : void //synapse will try to re-deliver all the Messages in the Message store.
deleteAll(): void // delete all the Messages in Message store
getMessageIds() : List<String> //gives IDs of all messages stored in the MessageStore
resend(String messageID) : void //try to re-deliver the Message with given ID
delete(String messageID) : boolean //delete the Message with given id
getEnvelope(String messageID) : SOAPEnvelope // get the SOAPEnvelope of the given Message ID
And added the feature to put a Mediation sequence with the Message store.So when a message get stored in the store uses can point to a sequence to mediate. This will be useful with notification mechanisms.
please review and commit
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Issue Comment Edited: (SYNAPSE-618) [GSoC] Implement a Dead
Letter Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913109#action_12913109 ]
Charith Dhanushka Wickramarachchi edited comment on SYNAPSE-618 at 9/21/10 1:48 PM:
------------------------------------------------------------------------------------
Hi Hiranya,
I added the MutiXML based configuration deployment for the DLC. Please have a look.And also i make the Message Store a synapse Artifact.
was (Author: charith):
Hi Hiranya,
I added the MutiXML based configuration deploment for the DLC. Please have a look.And also i Message Store a synapse Artifact.
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, messagestore_patch_8.diff, messagestore_patch_9.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Hiranya Jayathilaka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913905#action_12913905 ]
Hiranya Jayathilaka commented on SYNAPSE-618:
---------------------------------------------
Hi Charith,
I have checked in the basic message store API and the in-memory message store impl. I also checked in the JMX MBean and the sample you have provided. We can go ahead with those stuff for the 2.0 release. We'll keep the JMS message store for a later release. It would be great if you can provide some basic test cases for the configuration stuff.
Thanks,
Hiranya
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, messagestore_patch_8.diff, messagestore_patch_9.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_6.diff
Added the Java DoC improvements and a Sample guide to the Synapse Message store
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Hiranya Jayathilaka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846781#action_12846781 ]
Hiranya Jayathilaka commented on SYNAPSE-618:
---------------------------------------------
Hi Denis,
If you are willing to learn more on the subject, you can study the existing error handling mechanisms in Synapse. Synapse allows you to associate a fault sequence with every proxy service which is triggered in case of an error. Endpoints also have a good error handling implementation where we register an error handler before sending a message out and later invoke in case of an error (we maintain a stack of error handlers here). We should be able to leverage these existing error handling techniques to identify errors and push the messages into the dead letter channel.
You should also get familiar with the Synapse configuration model. Our configuration model is based on an XML configuration language. We use a set of factories to parse the XML syntax and construct the Synapse configuration object model. Implementing a dead letter channel would require some additions to the configuration language. So better to be familiar with it.
You can also have a look at some of the existing implementations of the dead letter channel pattern. Apache Camel supports this pattern out of the box. Looking at an existing implementation will help you understand the exact semantics of the pattern.
Thanks,
Hiranya
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Issue Comment Edited: (SYNAPSE-618) [GSoC] Implement a Dead
Letter Channel for Synapse
Posted by "Denis Weerasiri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846738#action_12846738 ]
Denis Weerasiri edited comment on SYNAPSE-618 at 3/18/10 4:25 AM:
------------------------------------------------------------------
Hi Asankha,
Regarding [1] , My mentor Milinda Pathirage on ODE-565 redirected Marco to me and he started to personally contact me, so I helped him and later he came up with more improvements to the code, such as removeGlobalBreakpoint(..) signature and implementation, using my ODE-565_3.patch (https://issues.apache.org/jira/secure/attachment/12412457/ODE-565_3.patch)
I added his code to the above mentioned JIRA today (https://issues.apache.org/jira/secure/attachment/12439113/Improvements-from-MarcoIndaco.rar). There's a README.txt, it contains the improvements.
And the changes I added there lager than 1MB are related to the front-end functionalities. As frankly I must say I was not able to complete the front end part as expected at the beginning of the Project. But I was able to came up with improvements to the back-end functionalities of ODE-debugger service.
Best Regards,
Denis Weerasiri
was (Author: ddweerasiri):
Hi Asankha,
Regarding [1] , My mentor Milinda Pathirage on ODE-565 redirect Marco to me and he started to personally contact me, so I helped him and later he came up with more improvements to the code, such as removeGlobalBreakpoint(..) signature and implementation, using my ODE-565_3.patch (https://issues.apache.org/jira/secure/attachment/12412457/ODE-565_3.patch)
I added his code to the above mentioned JIRA today (https://issues.apache.org/jira/secure/attachment/12439113/Improvements-from-MarcoIndaco.rar). There's a README.txt, it contains the improvements.
And the changes I added there lager than 1MB are related to the front-end functionalities. As frankly I must say I was not able to complete the front end part as expected at the beginning of the Project. But I was able to came up with improvements to the back-end functionalities of ODE-debugger service.
Best Regards,
Denis Weerasiri
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_2.diff
synapse_sample_1.xml
I added the redelivery mechanism as discussed in the mailing list.
current redelivery policies
interval : delay of redelivery (initial delay if exponential backoff is enable)
maximumRedeliveries : maximum number of redeliveries to attempt.
exponentialBackoff : enable /disable
if this is enable and backoffMutiplier is not set in default case it will try to redeiliver in the pattern:
interval : 2*interval : 3*interval : 4*interval
if backoffMutiplier is set
then pattern will be
interval : (backoffMutiplier ^1) * interval : (backoffMutiplier ^2 ) *interval
backoffMutiplier : mentioned above.
I had to introduse a new MessageContext propery while implementing this since i had to keep the message redelivery count.
And added a AbstractMessageStore since i feel like it will be useful in my future development.
I'm using Camel Dead Letter channel features as reference http://camel.apache.org/dead-letter-channel.html
please review and commit.
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_11.diff
added endpoint serialization for the attribute onFault = "message store name"
I saw the name attribute serialization code was repeated in several concrete classes . So i bring that code to a upper level to reuse the code by introducing the method serializeCommonAttributes
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_10.diff, messagestore_patch_11.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, messagestore_patch_8.diff, messagestore_patch_9.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_9.diff
Hi Hiranya,
I added the MutiXML based configuration deploment for the DLC. Please have a look.And also i Message Store a synapse Artifact.
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, messagestore_patch_8.diff, messagestore_patch_9.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_8.diff
Attached the patch providing changes Hiranya suggested.
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, messagestore_patch_8.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Hiranya Jayathilaka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912858#action_12912858 ]
Hiranya Jayathilaka commented on SYNAPSE-618:
---------------------------------------------
Hi Charith,
A few points to improve:
1. StoredMessage should be renamed to something more appropriate. I think StorableMessage is a more logical name looking at how it is being used throughout the code.
2. The package name messagestore does not sound right. I think it should be message.store or something like that
3. The PersistenceManager in the jms package should be renamed to something more descriptive. Howabout JMSPersistenceManager?
I'm thinking about adding the in-memory message store impl in the 2.0 release as an experimental thing. So it would be great if you can provide a patch with at least first 2 improvements asap.
-Hiranya
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Assigned: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Hiranya Jayathilaka (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hiranya Jayathilaka reassigned SYNAPSE-618:
-------------------------------------------
Assignee: Hiranya Jayathilaka
> [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
> Assignee: 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_5.diff
This patch add the MessageStore serialization capability to synapse.
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Denis Weerasiri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846536#action_12846536 ]
Denis Weerasiri commented on SYNAPSE-618:
-----------------------------------------
Hi devs,
I am Denis Weerasiri, a final year student from University of Moratuwa, Sri Lanka. I am hoping to participate in GSOC 2010 program. This would be my second GSOC. Last year I worked in and successfully completed Apache ODE project titled "Web-based BPEL debugger for Apache ODE". [1]
I would be willing to work on Apache Synapse project, under this idea. I have experience in developing applications with ESB, axis2, ODE etc. But upto now I'm still reading the code and documentation, and trying to understand implementing a message store.
Is there any other specific areas, I should consider regarding this to get a correct overall view of the project?
Best Regards,
Denis Weerasiri.
[1] - http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2009/asf/t124021709857
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Denis Weerasiri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846746#action_12846746 ]
Denis Weerasiri commented on SYNAPSE-618:
-----------------------------------------
Hi Asankha,
I really appreciate your comments. I'll remove the file I added to ODE-565. I was mistaken, attaching a file under " Attachment not intended for inclusion " is OK.
Best Regards,
Denis Weerasiri
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847329#action_12847329 ]
Amila Chinthaka Suriarachchi commented on SYNAPSE-618:
------------------------------------------------------
hi,
I recently send some patches handling this with WS-RM where ws-rm protocol can handle retransmissions and put it to an error sequence after given number of retransmissions.
In this case RM keeps the message in Memory.
you may have a look at that too.
thanks,
Amila.
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_4.diff
synapse_sample_1.xml
Attaching the patch for JMS Message store feature. and a test configuration file i used in my machine to test with this with ActiveMQ
This patch will contain
JMS Message store implementation
Message serializer for Axis2MessageContext and SynapseMessage context.
Due to the issue pointed out in
https://issues.apache.org/jira/browse/SYNAPSE-673
JMS message store will be supported only with global level endpoints. I'll fix the above issue and improve this implementation in the future.
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Commented: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Denis Weerasiri (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12846738#action_12846738 ]
Denis Weerasiri commented on SYNAPSE-618:
-----------------------------------------
Hi Asankha,
Regarding [1] , My mentor Milinda Pathirage on ODE-565 redirect Marco to me and he started to personally contact me, so I helped him and later he came up with more improvements to the code, such as removeGlobalBreakpoint(..) signature and implementation, using my ODE-565_3.patch (https://issues.apache.org/jira/secure/attachment/12412457/ODE-565_3.patch)
I added his code to the above mentioned JIRA today (https://issues.apache.org/jira/secure/attachment/12439113/Improvements-from-MarcoIndaco.rar). There's a README.txt, it contains the improvements.
And the changes I added there lager than 1MB are related to the front-end functionalities. As frankly I must say I was not able to complete the front end part as expected at the beginning of the Project. But I was able to came up with improvements to the back-end functionalities of ODE-debugger service.
Best Regards,
Denis Weerasiri
> [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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_7.diff
Added improvements to the current Persistence Message store
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
[jira] Updated: (SYNAPSE-618) [GSoC] Implement a Dead Letter
Channel for Synapse
Posted by "Charith Dhanushka Wickramarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SYNAPSE-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charith Dhanushka Wickramarachchi updated SYNAPSE-618:
------------------------------------------------------
Attachment: messagestore_patch_10.diff
Adding the Message Store Serialization Test .
> [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
> Assignee: Hiranya Jayathilaka
> Fix For: FUTURE
>
> Attachments: messagestore_patch_1.diff, messagestore_patch_10.diff, messagestore_patch_2.diff, messagestore_patch_3.diff, messagestore_patch_4.diff, messagestore_patch_5.diff, messagestore_patch_6.diff, messagestore_patch_7.diff, messagestore_patch_7.diff, messagestore_patch_8.diff, messagestore_patch_9.diff, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml, synapse_sample_1.xml
>
>
> 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: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org