Hi Charith, Good to see you making progress. I think we are off to good start.
On Sun, May 16, 2010 at 9:36 AM, Charith Wickramarachchi < charith.dhanus...@gmail.com> wrote: > > > 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. > I think we should keep our model simple and clean. Having this dual message store concept seems to make things complex. That way user is exposed to the low level implementation details of the DLC and user has too many things to configure (= worry about). You should be able to handle requirements like queuing up messages in the memory and then persisting them to the store in chunks in your implementation of the persisting DLC. We can of course provide some switches to the configuration language so the user can control certain aspects of the message store behavior. > >> 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. > +1 Exponential backoff would be more important in particular. RM is more like a nice to have feature right now. I think exponential backoff strategy should be built even into the simple redelivery policy that you have developed now. Looking forward for the patches :) Thanks, Hiranya > > >> 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/ > > -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
