[COMPASS-723] Increase ssh tunnel connection timeouts Created: 28/Jan/17 Updated: 11/Sep/19 Resolved: 11/Sep/19 |
|
| Status: | Closed |
| Project: | Compass |
| Component/s: | Connectivity |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Thomas Rueckstiess | Assignee: | Alena Khineika |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Epic Link: | COMPASS-1173 | ||||
| Story Points: | 1 | ||||
| Sprint: | Iteration Manatee | ||||
| Description |
|
We have a user in intercom complaining that he gets ssh timeouts, when RoboMongo connects to the instance ok. Currently, the timeout is hardcoded to 5 seconds in the connection-model. Increase to 30 seconds to account for geo latency. |
| Comments |
| Comment by Githook User [ 10/Sep/19 ] |
|
Author: {'name': 'Alena Khineika', 'username': 'alenakhineika', 'email': 'alena.khineika@gmail.com'}Message: |
| Comment by Githook User [ 05/Sep/19 ] |
|
Author: {'username': 'alenakhineika', 'email': 'alena.khineika@gmail.com', 'name': 'Alena Khineika'}Message: |
| Comment by Thomas Rueckstiess [ 11/Jul/17 ] |
|
Internally we are using ssh2, to which we pass the 3 options
readyTimeout in ssh2:
This seems to be the issue in the attached Intercom conversation as the error says "Error creating SSH Tunnel: Timed out while waiting for handshake". As the default is 20 seconds, we should perhaps just use the default here. The forwardTimeout is not documented on this page (does not exist in ssh2 source code), we should try to find out where this comes from and/or just go with the default. It's possible the forwardTimeout is not an option used in ssh2 but left-over from the previous ssh module we were using. The keepaliveInterval option is the frequency to send keepalive pings and should not be increased. |
| Comment by Peter Schmidt [ 03/Jul/17 ] |
|
Looking deeper, there are multiple timeouts here, and in light of the bugsnag it looks like it is common for servers to specify much longer keep alives like 60 seconds or even 240 seconds. Scratch my earlier thought about the status modal, increasing the keepalive timeout might be enough for most of these cases (where the user doesn't have something like RTSS permissions or other traffic going over the wire to keep the tunnel alive). |
| Comment by Peter Schmidt [ 03/Jul/17 ] |
|
While the timeout could be naively increased, this creates a suboptimal UX if the user has entered their details incorrectly. A substatus modal like on the schema view that times out at (the current 5?) seconds and prompts the user to retry with more time (say the 30s on this ticket) would be a better UX, but require more story points. |