On Wed, Sep 21, 2016 at 3:36 PM, Bill Erickson <beric...@gmail.com> wrote: > > On Wed, Sep 21, 2016 at 1:01 PM, Mike Rylander <mrylan...@gmail.com> wrote: >> >> On Wed, Sep 21, 2016 at 11:51 AM, Bill Erickson <beric...@gmail.com> >> wrote: >> > >> > On Wed, Sep 21, 2016 at 10:44 AM, Bill Erickson <beric...@gmail.com> >> > wrote: >> >> >> >> >> >> /osrf-http-translator provides a lower level OpenSRF API and supports >> >> streaming responses, but its use is no longer encouraged, because the >> >> underlying mechanism (multipart/x-mixed-replace) is deprecated and only >> >> works with our old version of XULRunner. This interface will likely be >> >> deprecated along with the XUL client. >> >> >> > >> > Couple of additional comments for those following along... >> > >> > 1. The multipart/x-mixed-replace part of the translator only affects its >> > ability to stream results. Without this, it's less efficient / fast, >> > but >> > still works. You just can't use it for API calls that return large >> > result >> > sets or for real-time use of individual results. The OpenSRF >> > API/session >> > support works regardless. >> > >> > 2. Various HTML interfaces outside of the XUL client proper (primarily >> > ACQ >> > and admin UI's) use the translator. All of these would have to be >> > ported to >> > websockets before we could consider deprecation. >> > >> >> Meaning, in the end, it'll be a while before the translator goes away, >> or is even deprecated except for streaming. >> >> In addition to the core users, it's simpler (admin- and code-wise) on >> both ends than WebSockets for little things and has the benefit of >> being able to supply transactional semantics even in a clustered >> environment, which I don't think our WebSockets implementation can do >> today (though, if it can, please do correct me!). > > > Clustered transactions should work much the same way with Websockets with a > few caveats. > > 1. Apache KeepAlive does not affect WS connections, so clients will not be > required to bounce between Apache servers mid-session after a (default) 1 > second timeout. There is a WS idle timeout setting, but it's intended to > drop clients after minutes of inactivity, not seconds. >
Well, that's configurable on the server, right? I can imagine cases where it would be beneficial to have a shorter inactivity timeout. Even with the much smaller RAM requirements, a large site could have 1500+ essentially quiescent connections. > 2. If a client is disconnected from an Apache WS backend, it will connect to > another Apache backend automatically and should be able to resume its > transaction (for "migratable" sessions), the same as an HTTP translator > client. At this point, I don't remember testing this specifically, but I > can't think of any reason it wouldn't work. Note to self: test this. > Right, it's the migratable session part I was unsure of. However, looking at the code, I don't think the websockets gateway handles that. It looks like it just uses an apache hash object, which (IIUC) is process-local. Am I misreading? --miker > The main difference between the HTTP and WS translator is how you gracefully > remove them from service in a clustered setup. For HTTP you "detach" from > the load balancer and give it time for any active requests to finish before > stopping Apache. For WS, you detach then issue a graceful Apache stop (or > restart), which tells the WS translator to kick off clients as soon as all > active requests are completed. When all clients are disconnected, the > shut-down completes. > >> >> Some background on the technology: even though some browsers don't >> support multipart/x-mixed-replace (most, other than IE, do at least >> for images -- it's used for simple webcam apps) we were far from the >> first to use it, and it's fairly trivial to implement on the client >> side. FWIW, curl supports it, so I wouldn't be too surprised to find >> clients in the wild using it. > > > Yes, all good points. I should have clarified that mixed/replace in > combination with XMLHttpRequest is the real issue here. That specifically > was only ever supported by FF, and eventually deprecated. > >> >> >> All that said, WebSockets is way better and if you write a new >> (future) client that uses the translator and multipart/x-mixed-replace >> for streaming then you are a bad person and you should feel bad. :) >> > > And pinesol_green will blame you for stealing all the tux dolls. > > -b >