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)
