-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
A Hub API that can query all running sessions. #6158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is missing tests, so it'll be easy to introduce accidental regressions.
The approach taken here is very "bare metal": we're basically exposing the internals of the current grid to the world. Is this the approach we want to take, or would we prefer something that explains the domain better? I'm perfectly happy if the answer is "bare metal to get us off the ground", as I think we're allowed to iterate on Grid functionality with greater freedom than anything on the client side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Both of these code paths are the same....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it. Initially I was thinking of supporting something like giving the ability to query sessions given a node. Forgot to remove the branching, when I didn't go forward with the implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please put variable declarations on separate lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have a json
field declared. Why not use that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is already going to be returned as a list of proxies. Having the word "proxy
" seems redundant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current sessions payload, has no information about the proxy. That is why added both the proxyId and proxyRemoteHost so that the user gets to know as to for which proxy does the sessions info belong to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of doing this, you can get the json coercer to do all the hard work:
Map<String, Object> body = json.newInput(reader).read(Json.MAP_TYPE);
Also, you're going to leak the JsonInput
: best open that in the try statement above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't want to indicate some form of error has occurred?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it. The status gets flipped to false
if there was any difficulty in extracting sessions info
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heavens. Just call rsp.getContent()
. You're not saving any memory doing this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed. I think I borrowed that code from somewhere :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this is rsp.getContentEncoding()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed.
cf61ab2
to
8fed148
Compare
I was initially confused as to what sort of tests I add because this new servlet internally makes a call to
The ask in #6070 was explicitly to have the capability of listing out all the sessions running in the Hub via an API. Please let me know if there's any other way of giving this capability. I will alter my PR accordingly. I have addressed the review comments. Please help take a look. |
@shs96c - thank you so much for merging the other two PRs. Can you please check if this one needs any additional work or if it can be merged as well ? |
Closes SeleniumHQ#6070 The API can be accessed via http://<IP:Port>/grid/api/sessions. Both GET and POST are supported and result in the same behavior. A typical response can look like below (intentionally trimmed the capabilities to reduce verbosity) { "proxies": [ { "proxyId": "http://192.168.1.6:5555", "proxyRemoteHost": "http://192.168.1.6:5555", "sessions": { "status": 0, "value": [ { "id": "df8aa16d-1d52-2e43-b584-2f9df586b0f3", "capabilities": {} }, { "id": "f85f5641-e6de-3642-913a-a45aafdb85ad", "capabilities": {} } ] } }, { "proxyId": "http://192.168.1.6:5556", "proxyRemoteHost": "http://192.168.1.6:5556", "sessions": { "status": 0, "value": [ { "id": "f4df4fbd-96ee-e042-ab43-40a33698d1e9", "capabilities": {} } ] } } ], "success": true }
8fed148
to
5f591bd
Compare
Rebased off of |
Closes SeleniumHQ#6070 The API can be accessed via http://<IP:Port>/grid/api/sessions. Both GET and POST are supported and result in the same behavior. A typical response can look like below (intentionally trimmed the capabilities to reduce verbosity) { "proxies": [ { "proxyId": "http://192.168.1.6:5555", "proxyRemoteHost": "http://192.168.1.6:5555", "sessions": { "status": 0, "value": [ { "id": "df8aa16d-1d52-2e43-b584-2f9df586b0f3", "capabilities": {} }, { "id": "f85f5641-e6de-3642-913a-a45aafdb85ad", "capabilities": {} } ] } }, { "proxyId": "http://192.168.1.6:5556", "proxyRemoteHost": "http://192.168.1.6:5556", "sessions": { "status": 0, "value": [ { "id": "f4df4fbd-96ee-e042-ab43-40a33698d1e9", "capabilities": {} } ] } } ], "success": true }
Closes #6070
The API can be accessed via
http://IP:Port/grid/api/sessions.
Both GET and POST are supported and result in the
same behavior.
A typical response can look like below (intentionally
trimmed the capabilities to reduce verbosity)
X
in the preceding checkbox, I verify that I have signed the Contributor License Agreement