I dislike having any logic based on the port number in some range; it's not common that behaviour would change if you set port to 9xxx instead of 8xxx.
Is there an (up-to-date) design doc? I don't fully follow, but if there's a problem in the HTTP handlers you can add a PING-detecting handler below...? Radim On 12/10/2018 03:27 PM, Sebastian Laskawiec wrote: > 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 > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <rva...@redhat.com> JBoss Performance Team _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev