A rule I've heard for UX is that anything over 200 ms is noticeable and anything over 2 s is slow. Unless polling every 500 ms is causing problems, it might be best to leave it at 500 ms as a decent compromise between efficiency and responsiveness.
Sarge > On 2 Feb, 2017, at 12:04, John Blum <jb...@pivotal.io> wrote: > >> The connection probably doesn't need to poll every 500ms. > > 500 ms provided a good (nearly consistent) UX for the user to know almost > instantly that the Manager went away, like the JMX counterpart. 2s is > arguable; 5s is probably too long as the user could already be typing > another command that is not available. In that case they might get another > kind of error (don't recall for sure). Anyway, food for thought. > > If another endpoint is needed (though I cannot imagine why) perhaps ` > securePing()` would be more descriptive and still offer up an alternative > route. > > > > On Thu, Feb 2, 2017 at 11:55 AM, Kevin Duling <kdul...@pivotal.io> wrote: > >> Good to know some history on it. The connection probably doesn't need to >> poll every 500ms. I would think 2 seconds or even 5 seconds would be >> sufficient in the general case. >> >> If we make ping require authentication, it may resolve the issue. But I'm >> not sure that's the right thing to do. We could create a 'ping2' endpoint >> (with some better name that I cannot currently think of) that does require >> auth for this thread to validate the connection. >> >> On Thu, Feb 2, 2017 at 11:49 AM, John Blum <jb...@pivotal.io> wrote: >> >>> Back in the day, I introduced this "polling thread" to determine whether >>> *Gfsh* was still connected, since as you say, in a HTTP "stateless" >>> environment and in the absence of a "persistent" connection, it otherwise >>> does not know. >>> >>> So, to simulate the behavior of *Gfsh* when connected via JMX RMI, I >> needed >>> to poll the Manager. That way when the Manager was no longer available, >> it >>> would display that *Gfsh* was no longer connected AND that the commands >>> that "require a connection" (e.g. `list region`) were no longer >>> available... again preserving the existing behavior in HTTP mode. >>> >>> Security (basic auth) had not been implemented in *Gfsh* at that time >> when >>> I created the Management REST API (or rather, it is more accurate to >> say... >>> REST-like; it's not a true REST-ful interface to be precise, which is one >>> reason it never was made public for users to consume, though it could >> have >>> been, providing we introduce the proper notion of REST-ful resources >>> abstractions and change the endpoints (URIs) appropriately; anyway...). >>> >>> -j >>> >>> >>> On Thu, Feb 2, 2017 at 11:08 AM, Kevin Duling <kdul...@pivotal.io> >> wrote: >>> >>>> Yes it does, immediately on the connect. So the behavior is different. >>>> >>>> On Thu, Feb 2, 2017 at 10:48 AM, Anthony Baker <aba...@pivotal.io> >>> wrote: >>>> >>>>> Seems odd to me that the ‘connect’ command is where the credentials >> are >>>>> supplied but the failures are only realized when invoking a secure >>>>> command. So I would need to go back and disconnect / reconnect to >> fix >>> a >>>>> password typo. >>>>> >>>>> As a reference point, does ‘connect’ over JMX surface authentication >>>>> errors? >>>>> >>>>> Anthony >>>>> >>>>>> On Feb 2, 2017, at 10:37 AM, Kevin Duling <kdul...@pivotal.io> >>> wrote: >>>>>> >>>>>> It's been reported in GEODE-2247 that gfsh can connect in a secured >>>>>> environment without a username/password when using the --use-http >>> flag. >>>>>> When using a jmx connection, this would immediately prompt for >>>>>> user/password. >>>>>> >>>>>> In the http environment, the connection isn't any less secure. The >>>>> moment >>>>>> one attempts to execute a command that an "anonymous user" cannot >>>>> execute, >>>>>> they will receive a failure with a message informing them that the >>> user >>>>> (in >>>>>> this case anonymous) cannot execute that command. That's all fine >>> and >>>>>> good, but the UX should probably be to fail instead on the >> 'connect' >>>> when >>>>>> in a secure environment. >>>>>> >>>>>> Opinions? >>>>>> >>>>>> The issue is that gfsh uses the 'ping' endpoint to determine >>>>> connectivity, >>>>>> which is not secured. Moreover, it starts a connection poll, >> hitting >>>>> that >>>>>> endpoint every 500ms to ensure the connection is still alive. I >>> can't >>>>>> determine why it's doing this other than to try to wrap an >> artificial >>>>>> 'state' in to the stateless nature of REST. The only advantage I >> see >>>> is >>>>>> that if I kill my server, gfsh knows right away that it's been >>>>> disconnected >>>>>> from it. >>>>>> >>>>>> I have not yet determined whether or not the socket stays open >>> through >>>>> all >>>>>> of this. I suspect that it does or otherwise I'd see a lot of >>> FIN_WAIT >>>>>> entries in my netstat results. >>>>>> >>>>>> One possible solution to this is to implement security in the >>> endpoint. >>>>>> But ShellCommandsContoller.java doesn't have any security in it. >>>>> Security >>>>>> is handled further downstream. >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> -John >>> john.blum10101 (skype) >>> >> > > > > -- > -John > john.blum10101 (skype)
