-
Notifications
You must be signed in to change notification settings - Fork 189
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
Be able to configure timeout on virtual switch ports #234
Comments
Previously we would time out connections after 5 minutes; this patch increases the timeout to 50 minutes as a test. This patch also logs the `Switch.remove` event as "info" so the failure should be more obvious. Related to moby#234 Signed-off-by: David Scott <[email protected]>
Previously we would time out connections after 5 minutes; this patch increases the timeout to 50 minutes as a test. This patch also logs the `Switch.remove` event as "info" so the failure should be more obvious. Related to moby#234 Signed-off-by: David Scott <[email protected]>
Thanks for your report. I suspect you're right about the timeout. As an experiment I made a PR (#235) with a small patch which bumps the timeout from 5 minutes to 50. Since it's a bit tricky to set up a build environment for vpnkit at the moment I recommend waiting for the CircleCI job to finish and then download the As it happens I used to work on omniORB but it's been quite a long time now. Your report brought back some memories! |
@joris-lammers the CircleCI build is ready. The build https://circleci.com/gh/moby/vpnkit/794 has an artefact link : https://794-58395340-gh.circle-artifacts.com/0/Users/distiller/vpnkit/vpnkit.tgz -- the archive contains a couple of subdirectories and the
|
Hmmm... no vpnkit binary in my install:
|
Ok, got it. It's now called |
It is working with the modified vpnkit |
Previously we would timeout switch ports after 300s of inactivity. Ideally active connections would be configured to send keep-alive packets sooner than this. To better support cases with no keep-alives, it's useful to be able to reconfigure the idle timeout (e.g. to make it much bigger). This patch adds - a command-line argument `--port-max-idle-time` - a database key `slirp/port-max-idle-time` which allow the default 300s to be overriden. Related to moby#235 Related to moby#234 Signed-off-by: David Scott <[email protected]>
Previously we would timeout switch ports after 300s of inactivity. Ideally active connections would be configured to send keep-alive packets sooner than this. To better support cases with no keep-alives, it's useful to be able to reconfigure the idle timeout (e.g. to make it much bigger). This patch adds - a command-line argument `--port-max-idle-time` - a database key `slirp/port-max-idle-time` which allow the default 300s to be overriden. Related to moby#235 Related to moby#234 Signed-off-by: David Scott <[email protected]>
Hi,
I am using a docker container to run regression tests (written in Python) using omniORB to communicate to the DUT.
Because of the omniORB interface to the DUT, we need to log in to the DUT before any API call is excepted and so we do. But sometimes, the opened TCP connection to the omniORB endpoint in the DUT is idle for multiple minutes after the initial logon. When finally, after for example 5 minutes, the regression script uses the IIOP API again, I believe vpnkit is opening a new connection from the OS X host to the DUT. But for the DUT, this new connection requires an logon first before any other API calls are excepted. However, from a regression script point of view, the connection has been established and has not changed. Result: failure of the script.
The README.md of this repo explains that the virtual switch will close the port when activity is absent for some time (not defined in README.md how long). This breaks the above regression framework we are using and I've already tried to reduce the keepalive timers in the container (to make sure there is at least data being sent over the idle connection) but for some reason that did not work.
So another way around the issue would be if I could extend the timeout in the virtual switch before it decides to open a new connection. Is there a way to do so?
The text was updated successfully, but these errors were encountered: