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.
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. 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. Thanks, Ruwan On Sat, May 15, 2010 at 10:18 PM, Charith Wickramarachchi < charith.dhanus...@gmail.com> 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 > http://charithwiki.blogspot.com/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > -- Ruwan Linton Software Architect & Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton google: http://www.google.com/profiles/ruwan.linton tweet: http://twitter.com/ruwanlinton
