@Udo- That is the thing. It is not just UI; the ping Thread is also there to properly set the state of *Gfsh* such that certain commands are not inappropriately made available as well (think *Gfsh* scripting, which if I remember correctly leads to a different type of error... NotConnectedException (with an appropriate message) vs. whatever the 404 translated to), regardless of the polling time.
On Thu, Feb 2, 2017 at 12:22 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > Not sure what the correct polling time would be... But we'd want to avoid > the situation where we poll too often. We could launch our own ping-attack. > > Also, this UX is not UI, so the difference between updating a screen with > new information vs checking if the connection is still valid... I'd err on > the side of caution and say... poll 2s and elgantly deal with a connection > failure when submitting an operation. > > --Udo > > > > On 2/2/17 12:07, Michael William Dodge wrote: > >> 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) >>> >> > -- -John john.blum10101 (skype)
