+1
I've found local caches very useful in multiple scenarios.
OT:
I was also thinking to standardize caches in order to create a sort of
short-circuit mechanism, e.g. to avoid overloading external systems with
repeated queries. Something like...
```
from("xxx")
.cache().on("${header.yyy}").ttl(600000) // caches the body
.to("http4://
a-service-that-makes-me-pay-for-each-request.com/api/expensive-endpoint")
.transform().zzz()
.to("http4://
or-a-service-that-i-can-call-few-times-a-day.com/api/limited-endpoint")
.unmarshal()
.endCache()
```
But also to protect internal services when I'm using Camel e.g. as a
api-gateway (almost what hystrix does in case of failure of the target
host).
On Wed, Apr 5, 2017 at 9:59 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:
> +1
>
> Yeah better to have it be like the other components.
>
>
> On Wed, Apr 5, 2017 at 9:47 AM, Luca Burgazzoli <lburgazz...@gmail.com>
> wrote:
> > Hi everyone,
> >
> > I've opened an issue [1] to change the uri syntax of camel-infinispan
> > so that it will be similar to the other cache implementations we have
> > in camel (hazelcast, ehcache, jcache). As additional benefit it would
> > make it easy to perform auto configuration of the component in
> > spring-boot maybe leveraging infinsipan's spring-boot starter [2] when
> > we'll migrate to infinispan 9.0
> >
> > Is there anything I missed that would make this change not possible ?
> >
> > [1] https://issues.apache.org/jira/browse/CAMEL-11108
> > [2] https://github.com/infinispan/infinispan-spring-boot
> >
> >
> > ---
> > Luca Burgazzoli
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
