synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charith Wickramarachchi <>
Subject Re: Synapse Message Store
Date Sun, 16 May 2010 04:06:18 GMT
On Sun, May 16, 2010 at 12:03 AM, Ruwan Linton <>wrote:

> Hi Charith,
> The implementation seems to be pretty straight forward by reading your
> explanation. To start with inMemory message store will work, but for any
> useful scenario DLC should be persistable, meaning that the message store
> has to support persistence.

> Yap actually implementing a JMS based Message store is a part of My project

> When it comes to implementation, it is good if we can use a hybrid message
> store where it first keep messages in-memory and then persists to some
> persistence mechanism.

how about adding a feature to the Message store to have a secondary Message
store so that after a certain Message limit in coming messages to primary
message store they will get persist in the secondary store.(will look smiler
to a memory hierarchy)And also in case of a synapse shut-down it will also
try to persist all stored messages via the secondary store.

> Being said all that, I see a lot of similarities in the failover endpoint
> and this approach, and moving forward, you will need to implement the
> exponential back-off for retrying and so forth. I wonder whether we can
> re-use the failover endpoint to achieve this. I didn't think through this,
> but it seems it is possible to associate the DLC with failover endpoint and
> leverage the retry functionality from the failover endpoint.
>     even though in my current POC it supports a simple re try interval. it
will support policies like exponential back-off and RM based   re- delivery.

> Thanks,
> Ruwan
> On Sat, May 15, 2010 at 10:18 PM, Charith Wickramarachchi <
>> wrote:
>> Hi devs,
>> After looking in to the code of i was able to implement a POC of InMemory
>> Message store for the Synapse with a simple redelevery processor.
>> I'll explain the current implementation.
>> Message Store is a top level element. And It has a associated redelivery
>> processor .
>> I'm assuming there can be Multiple implementations of Message stores so i
>> m having an abstraction of Message Store.
>> My current implementation is a InMemory One. and its associated with
>> failures of endpoints.
>> End point can point to a message store ,so on Fault the Messages will get
>> stored with the endpoint details.
>> Redelivery processor will unstore the Messages from the Message store and
>> try to redeliver it with original
>> endpoint (current re delevery policy is a simple re try interval).
>> Since in accual industry senarios due to the Message load is high inMemory
>> message store can cause high memory
>> usage that can cause system to become unstable. So i'm thinking of
>> limiting the numbers of Messages for the InMemory Store.
>> WDYT ? i m happy to hear better solutions for the Memory issue that i
>> explaied above.
>> In a persisting Message store i'll have to remove un nessory memory
>> refferences like SynapseEnvinment , Axis2Context.(in case of serialsing the
>> Message)
>> But in Inmemory case it doest seems like removing them will add much of an
>> advantage since thay just are references.
>> GSoC2010 coding officialy starts on 24th of May i'll try to  provide my
>> 1st patch before that.
>> i m attching the sample synapse configuration that i'm using to test my
>> implementaion
>> thanks,
>> /Charith
>> --
>> Charith Dhanushka Wickramarachchi
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Ruwan Linton
> Software Architect & Product Manager, WSO2 ESB;
> WSO2 Inc.;
> Lean . Enterprise . Middleware
> phone: +1 408 754 7388 ext 51789
> email:; cell: +94 77 341 3097
> blog:
> linkedin:
> google:
> tweet:

Charith Dhanushka Wickramarachchi

View raw message