Re: [infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

Let me explain why it is there first :) This class was added for two main reasons: as a replacement for compatibility and for supporting equality of byte[] object. What this class does is at the user side is box the given arguments (eg. byte[] -> WrappedByteArray) then the cache only ever deals

Re: [infinispan-dev] Using load balancers for Infinispan in Kubernetes

Cool down peoples! http://www.quickmeme.com/meme/35ovcy Sebastian, don't think Sanne was being rude, he's just blunt and we need his bluntness :) Sanne, be nice to Sebastian and get him a beer next time around ;) Peace out! :) -- Galder Zamarreño Infinispan, Red Hat > On 31 May 2017, at

Re: [infinispan-dev] Proposal for moving Hibernate 2l provider to Infinispan

Just a heads up - FWIW I doubt my reply goes through to the entire infinispan-dev list. Replies inline... 3. What should be the artifact name? Should it be 'hibernate-infinispan' > like it is today? The difference with the existing cache provider would be > the groupId. Or some other artifact

[infinispan-dev] Proposal for moving Hibernate 2l provider to Infinispan

Hi all, Given all the previous discussions we've had on this list [1] [2], seems like there's a majority of opinions towards moving Infinispan Hibernate 2LC cache provider to the Infinispan repo. Although we could put it in a completely separate repo, given its importance, I think we should

[infinispan-dev] Allocation costs of TypeConverterDelegatingAdvancedCache

Hi all, I've been running some benchmarks and for the fist time playing with Infinispan 9+, so please bear with me as I might shoot some dumb questions to the list in the following days. The need for TypeConverterDelegatingAdvancedCache to wrap most operations - especially "convertKeys" - is

[infinispan-dev] Infinispan 9.1.0.Alpha1 Released

Dear All, Infinispan 9.1.0.Alpha1 has been released: http://blog.infinispan.org/2017/05/infinispan-910alpha1-released.html Cheers Ryan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

Re: [infinispan-dev] HotRod client TCK

Hey Galder, thanks a lot for review. I have updated the document based on your suggestions. Best regards, Anna. - Original Message - From: "Galder Zamarreño" To: "infinispan -Dev List" Sent: Monday, May 8, 2017 1:32:13 PM Subject: Re:

Re: [infinispan-dev] Using load balancers for Infinispan in Kubernetes

Hey Sanne, Comments inlined. Thanks, Sebastian On Tue, May 30, 2017 at 5:58 PM Sanne Grinovero wrote: > Hi Sebastian, > > the "intelligent routing" of Hot Rod being one of - if not the main - > reason to use Hot Rod, I wonder if we shouldn't rather suggest people to >

Re: [infinispan-dev] Using load balancers for Infinispan in Kubernetes

On 05/30/2017 04:46 PM, Sanne Grinovero wrote: > Hi Sebastian, > > the "intelligent routing" of Hot Rod being one of - if not the main - > reason to use Hot Rod, I wonder if we shouldn't rather suggest people > to stick with HTTP (REST) in such architectures. > > Several people have suggested in

Re: [infinispan-dev] Using load balancers for Infinispan in Kubernetes

To Sanne’s point, I think HTTP(/2) would be a better longer term path if we think we can make it as efficient as current HR. But let’s evaluate the numbers of cycles to reach that point. Doing Seb’s approach might be a good first step. Speaking of Sebastian, I have been discussing with Burr,