[infinispan-dev] Single Port Client

[Sebastian Laskawiec]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20181210/b3cd1707/attachment.html