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, Edso
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
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
> stick with HTTP (REST) in
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: [infinispan-dev] HotRod client TCK
Btw, thanks Ann
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
https://lists.jboss.org/mailman/listinfo/infinispan-de
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 high
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 ke
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 id
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 09:3
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
wit
On 31 May 2017 at 17:48, Galder Zamarreño wrote:
> 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 ;)
Hey, he started it
11 matches
Mail list logo