> On 1. May 2020, at 01:43, Scott Lewis <[email protected]> wrote: > > Howdy, > > Apologies if I'm misinterpreting Mike's comments below as I was not able to > attend this presentation (but will watch it when available). > > On 4/30/2020 2:20 PM, Mike Hummel wrote: >> Hello, >> >> <stuff deleted> >> >> - A common topic for clustering is a common cache and locking. It's possible >> with hazelcast. But I was not able use hazelcasts caching service - lots of >> class loader issues. I was able to use ehcache (no locking) and redis for >> this features. It's a shame that specially 'java caching api' is not >> possible in OSGi using hazelcast. It's also not easy with ehcache but I >> found a workaround. > > [Scott] It seems possible to me that remote services could be useful for > creating such a 'java caching api', and ECF has a distribution provider based > upon hazelcast [1]...allowing a nice separation between 'caching api' (set of > interacting osgi services), implementation (OSGi service impls) and > distribution (Hazelcast and/or other distribution providers). > [Mike] hazelcast implement JSR 107, but it's not possible to use it in OSGi. I tried it here https://github.com/mhus/mhus-osgi-dev/blob/master/dev-cache/src/main/java/de/mhus/osgi/dev/cache/CmdDevHazelcast.java <https://github.com/mhus/mhus-osgi-dev/blob/master/dev-cache/src/main/java/de/mhus/osgi/dev/cache/CmdDevHazelcast.java> but it's not working because of class loading issues. Using ehcache was also not easy, I had to copy some classes because classes are not public - example is in the same repo. But its working with the hack. - I used the hazelcast coming with cellar.
>> <stuff deleted> >> >> I found the presentation of Dimitry very helpful. I will try not to divide >> each service in a separate container. In this scenario it's also possible to >> share database entities in the same JVM engine - this will even boost the >> performance - instead of using it via rest all the time. >> >> Also interesting is the support of API gateways. For me a big problem is the >> service discovery. It's absolutely stupid to configure each service manually >> in the API gateway. A more comfortable way would be some kind of discovery. >> Karaf could automatically configure/update the gateway depending on the >> provided jax rs resources. > > WRT service discovery...remote services specifies service discovery using an > arbitrary comm protocol, and ECF has a discovery provider based upon etcd > [1], which is also used in Kubernetes I believe. With this etcd provider > [2], I expect that creating a Kubernetes remote service publish/discovery > would be straightforward. > Thanks for the https://github.com/ECF <https://github.com/ECF> hint. I need to discover it next week. Seams to have solutions for some common problems. Regards, Mike > > Scott > > [1] https://github.com/ECF/HazelcastProvider > > [2] https://github.com/ECF/etcd-provider > >
signature.asc
Description: Message signed with OpenPGP
