Hi Hiranya, Actually our original intention was to introduce pre-fetching for the registry entries. But then we realized that the caching in mixed with the registry of the synapse. Ideally registry is the content provider. But we use the registry for caching as well. This makes the synchronization difficult and all over the place. Also it seems that the current implementation will become messy if we implement things like asynchronous fetching in the current implementation.
That is why we though of separating out the cache from the registry. Thanks, Supun.. On Tue, Jan 11, 2011 at 12:07 AM, Hiranya Jayathilaka <[email protected]> wrote: > Hi Supun > > On Mon, Jan 10, 2011 at 12:01 PM, Supun Kamburugamuva <[email protected]> > wrote: >> >> I think cache is not something a user should think in terms of >> mediation. So I'm thinking that it should go in to a separate file. >> Only the people who write code will see the cache. > > So this is a plus point for the current cache implementation right? > Currently for a normal Synapse user, the cache is completely transparent. > For instance a user can do: > <endpoint key="foo"/> > The endpoint will be imported from the registry and cached locally without > the user knowing it. But developers who write code on top of Synapse can > access the cache directly. > >> >> This lead us to think about the Registry definition in the synapse.xml >> as well. The registry definition that is in the synapse.xml is not >> related to mediation as well. It is a static configuration that is >> ideally put in a separate file. > > Well with the new config model, it's already in a separate file named > registry.xml. Perhaps what we should do it just take it off the > SynapseConfiguration and have it independently. > Thanks, > Hiranya > >> >> Thanks, >> Supun.. >> >> On Mon, Jan 10, 2011 at 11:53 AM, Ruwan Linton <[email protected]> >> wrote: >> > Also you have neglected my question on the relation to the configuration >> > language with this, or are you planning to make this completely >> > transparent >> > from the user? >> > Ruwan >> > >> > On Mon, Jan 10, 2011 at 11:52 AM, Ruwan Linton <[email protected]> >> > wrote: >> >> >> >> >> >> On Mon, Jan 10, 2011 at 11:35 AM, Udayanga Wickramasinghe >> >> <[email protected]> wrote: >> >>> >> >>> Hi Ruwan, >> >>> >> >>> On Mon, Jan 10, 2011 at 10:32 AM, Ruwan Linton >> >>> <[email protected]> >> >>> wrote: >> >>>> >> >>>> Udayanga, may I know some usecases for this cache implementation?? >> >>>> Synapse is not designed for the users to interact with the API >> >>>> directly. It >> >>>> has a configuration language to access the API (in most of the cases, >> >>>> apart >> >>>> from the Class mediator and so forth, and the class mediator has to >> >>>> be your >> >>>> last option). >> >>> >> >>> One of the use cases is implementing a prefetcher. We can define a >> >>> prefetching criteria under cache so that certain entries(ie:-xslt,wsdl >> >>> , >> >>> etc) are prefetched and cached upfront to enhance performance. So at >> >>> runtime >> >>> remote entries/item collections could be prefetched from cache , >> >>> without >> >>> contacting the registry first(otherwise first query would always be to >> >>> a >> >>> remote reg) .Also whenever remote reg is down we can query prefetched >> >>> cache >> >>> instead (and can easily employee a back-off criteria depending on the >> >>> window of failure ) . Another use case may be implementing a >> >>> distributed >> >>> cache when multiple registry/esb instances are running . Implementing >> >>> these >> >>> scenarios under current context tis hard because of the reasons i have >> >>> mentioned earlier. >> >> >> >> I don't think you need a separate cache to implement pre-detching?? We >> >> already cache the remote registry entries at the Configuration, >> >> implementing >> >> pre-fetching is just a matter of time at which you make the first call, >> >> isn't it?? it is just a switch required to check whether you want to >> >> work >> >> from the local cache when the remote registry is down, and continue >> >> using >> >> the local cache. This can be simply implemented with the existing >> >> context >> >> :-( >> >> How do you implement a distributed cache? what is the replication >> >> mechanism that you are planning to use, we do replicate stuff with >> >> Axis2 >> >> clustering implementation already. >> >> Thanks, >> >> Ruwan >> >> >> >>> >> >>> Regards, >> >>> Udayanga >> >>> >> >>> >> >>> -- >> >>> Udayanga Wickramasinghe >> >>> Software Engineer; WSO2 Inc.; http://wso2.com, >> >>> email: [email protected] cell: +94 (77) 983-4365 >> >>> blog: http://udayangawiki.blogspot.com >> >>> twitter: http://twitter.com/udayanga_wick >> >>> >> >> >> >> >> >> >> >> -- >> >> Ruwan Linton >> >> Software Architect & Product Manager >> >> WSO2 Inc.; http://wso2.org >> >> >> >> Lean . Enterprise . Middleware >> >> >> >> phone: +1 408 754 7388 ext 51789 >> >> email: [email protected]; 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 >> > >> > >> > >> > -- >> > Ruwan Linton >> > Software Architect & Product Manager >> > WSO2 Inc.; http://wso2.org >> > >> > Lean . Enterprise . Middleware >> > >> > phone: +1 408 754 7388 ext 51789 >> > email: [email protected]; 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 >> > >> >> >> >> -- >> Technical Lead, WSO2 Inc >> http://wso2.org >> supunk.blogspot.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Hiranya Jayathilaka > Senior Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > -- Technical Lead, WSO2 Inc http://wso2.org supunk.blogspot.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
