On Sun, May 16, 2010 at 12:03 AM, Ruwan Linton <ruwan.lin...@gmail.com>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. > +1 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 < > 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 > -- Charith Dhanushka Wickramarachchi http://charithwiki.blogspot.com/
