Re: [infinispan-dev] Hot Rod secured by default

You want to use OpenSSL with Netty: http://netty.io/wiki/requirements-for-4.x.html#wiki-h4-4 Tristan On 31/03/2017 15:55, Sebastian Laskawiec wrote: > Unfortunately TLS still slows down stuff (a lot). When I was doing tests > for the multi-tenancy router (which is based on TLS/SNI), my average

Re: [infinispan-dev] Single Endpoint design

With TLS+ALPN the use case is very simple. The protocol is negotiated during the handshake. Then the existing TCP connection is reused and the client starts to send Hot Rod binary bits through the wire. Sadly, TLS adds some significant overhead to the transmission. With HTTP/1.1 Upgrade it's a

Re: [infinispan-dev] Infinispan Designs repository

Already done sir. Tristan On 31/03/2017 15:20, Emmanuel Bernard wrote: > Should we (as in someone specific that is not me) migrate all the GitHub > proposal / design pages from the Wiki? > >> On 31 Mar 2017, at 14:25, Tristan Tarrant wrote: >> >> As was pointed out by

Re: [infinispan-dev] Infinispan Designs repository

+1. I would also replace migrated documents with links to the new repo. On Fri, Mar 31, 2017 at 3:52 PM Emmanuel Bernard wrote: > Should we (as in someone specific that is not me) migrate all the GitHub > proposal / design pages from the Wiki? > > > On 31 Mar 2017, at

Re: [infinispan-dev] Strategy to adopting Optional in APIs

I like the idea of using Optionals. But I think we would need to enhance all our APIs to use this (to be consistent). Maybe you could come up with a small proposition of API changes? It might not work correctly (we can just mock them) but I would love to see some examples and "feel" the

Re: [infinispan-dev] Hot Rod secured by default

Unfortunately TLS still slows down stuff (a lot). When I was doing tests for the multi-tenancy router (which is based on TLS/SNI), my average results were like this: Use-case Type Avg Error initConnectionAndPerform10KPuts SingleServerNoSsl 1034.817 14.424 initConnectionAndPerform10KPuts

Re: [infinispan-dev] Strategy to adopting Optional in APIs

Maybe yes, maybe not... in my experience escape analysis is very fickle, e.g. it's very easy for a method to become big enough after inlining that escape analysis is not performed at all. Dan On Fri, Mar 31, 2017 at 10:59 AM, Tristan Tarrant wrote: > I was about to say the

Re: [infinispan-dev] Infinispan Designs repository

Should we (as in someone specific that is not me) migrate all the GitHub proposal / design pages from the Wiki? > On 31 Mar 2017, at 14:25, Tristan Tarrant wrote: > > As was pointed out by Sebastian, GitHub's wiki doesn't really take > advantage of the wonderful review

[infinispan-dev] Infinispan Designs repository

As was pointed out by Sebastian, GitHub's wiki doesn't really take advantage of the wonderful review tools that are instead available for traditional repos. Instead of creating noise in the main infinispan repo, I have setup a dedicated repo for design ideas. Let's fill it up !

Re: [infinispan-dev] Single Endpoint design

No, once the connection is established, I believe the netty pipeline can be trimmed to the necessary elements. Tristan On 31/03/2017 13:57, Gustavo Fernandes wrote: > On Fri, Mar 31, 2017 at 11:02 AM, Tristan Tarrant > wrote: > > You

Re: [infinispan-dev] Single Endpoint design

On Fri, Mar 31, 2017 at 11:02 AM, Tristan Tarrant wrote: > You understood incorrectly. > The only change to the Hot Rod clients is that, if they get a 400 error > from a HR PING request, they will initiate an upgrade to Hot Rod and > then proceed with the usual Hot Rod

Re: [infinispan-dev] Infinispan 9.0 Final

That looks awesome. Congratulations everyone! Now I'll start filing new issues from my wishlist for Hibernate OGM ;-) Thanks, Sanne On 31 March 2017 at 10:09, Tristan Tarrant wrote: > Dear all, > > we are proud to announce Infinispan 9.0 Final. > This release includes

Re: [infinispan-dev] Single Endpoint design

You understood incorrectly. The only change to the Hot Rod clients is that, if they get a 400 error from a HR PING request, they will initiate an upgrade to Hot Rod and then proceed with the usual Hot Rod protocol after that. Tristan On 31/03/2017 11:58, Gustavo Fernandes wrote: > Hi

Re: [infinispan-dev] Single Endpoint design

Hi Sebastian, If I understood it correctly, all the Hot Rod clients will be changed from using: - Binary over TCP, circa 40 bytes header, no hops to contact the server, no protocol negotiation, no encryption (default) to - HTTP/2 with SSL, protocol upgrade negotiation, and a hop (router) to

[infinispan-dev] Infinispan 9.0 Final

Dear all, we are proud to announce Infinispan 9.0 Final. This release includes many new features and improvements: - much improved performance in all scenarios - off-heap data container, to avoid GC pauses - Ickle, a new query language based on JP-QL with full-text capabilities - multi-tenancy

Re: [infinispan-dev] Strategy to adopting Optional in APIs

I was about to say the same: in the typical use case of returning an optional and using it immediately it would probably end up on the stack anyway... Tristan On 31/03/2017 09:57, Radim Vansa wrote: > I secretly hope that all these allocations would be inlined and > eliminated. If we find out

Re: [infinispan-dev] Strategy to adopting Optional in APIs

I secretly hope that all these allocations would be inlined and eliminated. If we find out that it really allocates the objects (from JFR's allocation stats), it's a reason to rewrite that piece of code to the dull optionless version. TBH I am rather afraid that the JVM will allocate the