synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charith Wickramarachchi <charith.dhanus...@gmail.com>
Subject Re: [jira] Created: (SYNAPSE-618) [GSoC] Implement a Dead Letter Channel for Synapse
Date Sat, 27 Mar 2010 09:05:59 GMT
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
>>>> <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/

Mime
View raw message