Re: [infinispan-dev] Single Port Client

Hey guys, During Infinispan F2F, I had a short discussion with Tristan on Single Port client-side implementation. Back then, we agreed that the client should always send a Hotrod Ping request and if won't get any response (or get some HTTP content back), it will try to upgrade to the Hotrod protocol using Single Port. I've been playing with the implementation for a while, and implementing it this way seems a bit "inconvenient" to me. The Ping Operation uses 60s timeout, which seems to be a good fit as a default. Unfortunately, for the Single Port functionality, this means we'd need to wait 60s until we try to send HTTP request and do an upgrade. Also, another problematic part is in Netty's HTTP handlers (HttpObjectDecoder, HttpServerCodec and ByteToMessageDecoder). When those classes fail to decode a message (REST expects HTTP rather than a stream of bytes specific to Hotrod protocol), they just ignore it and keep the channel in active state (which also makes sense for HTTP/1.1 and HTTP/2). At this point, my intuition tells, that this doesn't look right and seems to be a over-complicated. The whole HTTP upgrade idea seems to work the other way around, use HTTP as a fallback and then upgrade to other protocols. Forcing it to work a bit differently requires some more effort. What if we preserved the Single Port setting in the client configuration but implemented it as an enum with the following values - true/false/auto. In automatic mode, the client would check if the server port is set to 8\d{1,3} (this covers 80, 8080, 8081, 8443 and friends). If that is true, we'd try to follow HTTP Upgrade procedure. This looks very simple and I think this might actually work. Please note, that we need the single port setting in the client configuration to cover some corner cases like the Single Port exposed on different port (like 4444) or Hot Rod exposed on port that starts with 8. What do you think about such simplification? Thanks, Sebastian