synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiranya Jayathilaka <hiranya...@gmail.com>
Subject Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter Channel for Synapse
Date Thu, 01 Apr 2010 05:20:46 GMT
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
>> <charith.dhanushka@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
>> > <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
>> >>>>> <charith.dhanushka@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
>> >>>>> > <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/
>> >>>>> >
>> >>>>> >
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> 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

Mime
View raw message