Use unix socket proxy on OS X instead of netty KQueue route#410
Use unix socket proxy on OS X instead of netty KQueue route#410
Conversation
looking up configured docker client provider. Add an informative log message instead.
always used on OS X where possible.
CHANGELOG.md
Outdated
| - Worked around incompatibility between Netty's Unix socket support and OS X 10.11. Reinstated use of TCP-Unix Socket proxy. (Fixes #402) | ||
|
|
||
| ### Changed | ||
| - Updated docker-java to 3.0.12 (#393) |
There was a problem hiding this comment.
wrong record, was changed in 1.4.0
There was a problem hiding this comment.
Bleh, good point. Something went wrong during changelog merge - same as below.
CHANGELOG.md
Outdated
| - Fixed erroneous version reference used during CI testing of shaded dependencies | ||
| - Fixed leakage of Vibur and Tomcat JDBC test dependencies in `jdbc-test` and `mysql` modules (#382) | ||
| - Added timeout and retries for creation of `RemoteWebDriver` (#381, #373, #257) | ||
| - Fixed double encoding of listNetwork's filter until it's fixed in docker-java (#385) |
There was a problem hiding this comment.
why? 1.4.1 was released already, we can't change the changelog for it :)
core/pom.xml
Outdated
| <!-- replace with junixsocket --> | ||
| <exclusion> | ||
| <groupId>de.gesellix</groupId> | ||
| <artifactId>unix-socket-factory</artifactId> |
There was a problem hiding this comment.
I'm not sure this dependency is there in 3.0.12, probably unnecessary
|
|
||
| private boolean shouldCheckWithCommand() { | ||
| // Special case for Docker for Mac, see #160 | ||
| if(!DockerClientFactory.instance().isUsing(DockerMachineClientProviderStrategy.class) |
There was a problem hiding this comment.
I would keep it, this should apply to both Proxied & direct access
| } catch (InstantiationException | IllegalAccessException | ClassNotFoundException e) { | ||
| LOGGER.warn("Can't instantiate a strategy from " + it, e); | ||
| } catch (ClassNotFoundException e) { | ||
| LOGGER.warn("Can't instantiate a strategy from {} (ClassNotFoundException). " + |
| import java.nio.file.Paths; | ||
|
|
||
| @Slf4j | ||
| public class UnixSocketClientProviderStrategy extends DockerClientProviderStrategy { |
There was a problem hiding this comment.
I wouldn't change this strategy. It works great for OS X >= 10.12 users, we should use it if OSX's version is >= 10.12, and Proxied if < 10.12
There was a problem hiding this comment.
I don't know; the proxied approach seems to be pretty solid and AFAICT the main benefit of the netty KQueue enhancement is design elegance - it lets us remove a hack (albeit a reliable one).
If we can't remove the hack anyway, then do we gain much from having a new potential way of working on OS X?
I need to think about this when I don't have such a headache 😄
There was a problem hiding this comment.
I had a feeling that KQueue is faster on my machine, but I might be wrong :)
There was a problem hiding this comment.
I ran some simple JMH benchmarks, comparing performance for both creating a container and just retrieving a container listing. TLDR; the docker daemon is the bottleneck for heavy operations, and there's a small performance boost with KQueue, but probably not significant especially given how infrequently we call it:
Benchmark Mode Cnt Score Error Units
ClientPerfBenchmark.directClientCreatingContainers thrpt 20 9.839 ± 0.340 ops/s
ClientPerfBenchmark.directClientJustListing thrpt 20 435.923 ± 117.758 ops/s
ClientPerfBenchmark.proxiedClientCreatingContainers thrpt 20 10.085 ± 0.663 ops/s
ClientPerfBenchmark.proxiedClientJustListing thrpt 20 202.696 ± 43.040 ops/s
However, I'm coming around to using the KQueue route on macOS 10.12+, as it will help us establish confidence in this netty component for the future.
| - Added `getFirstMappedPort` method (#377) | ||
| - Extracted Oracle XE container into a separate repository ([testcontainers/testcontainers-java-module-oracle-xe](https://github.com/testcontainers/testcontainers-java-module-oracle-xe)) | ||
| - Added shading tests | ||
| - Updated docker-java to 3.0.12 (#393) |
| // Special case for Docker for Mac, see #160 | ||
| if(!DockerClientFactory.instance().isUsing(DockerMachineClientProviderStrategy.class) | ||
| && System.getProperty("os.name").toLowerCase().contains("mac")) { | ||
| if ((DockerClientFactory.instance().isUsing(ProxiedUnixSocketClientProviderStrategy.class) || |
There was a problem hiding this comment.
I think previous code (not docker machine and Mac) should cover both cases. Also, this change has a bug because || has lower priority than &&
There was a problem hiding this comment.
I'm afraid I can't see the bug - brackets? Obviously this means the code should be clearer though 😆
| return PRIORITY; | ||
| protected boolean isApplicable() { | ||
| return SystemUtils.IS_OS_LINUX || | ||
| (SystemUtils.IS_OS_MAC_OSX && !SystemUtils.OS_VERSION.startsWith("10.11")); |
There was a problem hiding this comment.
we have ComparableVersion, maybe we should use it instead of startsWith?
There was a problem hiding this comment.
Of course - I forgot about my own class.
|
|
||
| @Override | ||
| protected boolean isApplicable() { | ||
| return !SystemUtils.IS_OS_LINUX && socketFile.exists(); |
There was a problem hiding this comment.
We probably shouldn't apply it if OSX and >= 10.12
|
It seems to be working now, thank you! :) |
| // Special case for Docker for Mac, see #160 | ||
| if(!DockerClientFactory.instance().isUsing(DockerMachineClientProviderStrategy.class) | ||
| && System.getProperty("os.name").toLowerCase().contains("mac")) { | ||
| if (DockerClientFactory.instance().isUsing(DockerMachineClientProviderStrategy.class) && |
There was a problem hiding this comment.
ooops, I think we have a bug here, should be "if NOT" (see the diff)
|
seems not work for me with the SNAPSHOT. OS: macOS 10.11.6 |
|
@email2liyang seems like an issue with Netty: netty/netty#6855 |
|
Also, what exactly didn't work? Because it seems to be just a noisy logging |
|
@bsideup , I'm using an elasticsearch image for es related test, seems the snapshot version can't start es container successfully, we could reproduce this issue with steps below
the same command works in master branch where I depends on |
|
@email2liyang yeah, that will be fixed soon (see my last review comment) :) |
|
@bsideup ,yes confirmed that v1.4.2 works in macOS 10.11, but still get the warning exception like below which related to netty/netty#6855 any idea on when it will get fixed? |
Bumps [amqp-client](https://github.com/rabbitmq/rabbitmq-java-client) from 3.5.3 to 5.5.1. <details> <summary>Release notes</summary> *Sourced from [amqp-client's releases](https://github.com/rabbitmq/rabbitmq-java-client/releases).* > ## 5.5.1 > This is a patch release with a bug fix. All users of the 5.x.x series are encouraged to upgrade to this version. > > # Changes between 5.5.0 and 5.5.1 > > ## Record recoverable entities in RPC channel methods > > GitHub issue: [#425](https://github-redirect.dependabot.com/rabbitmq/rabbitmq-java-client/issues/425) > > ## 5.5.0 > This is a maintenance release with 2 new features and a bug fix. All users of the 5.x.x series are encouraged to upgrade to this version. > > # Changes between 5.4.3 and 5.5.0 > > ## Add traffic listener > > GitHub issue: [#411](https://github-redirect.dependabot.com/rabbitmq/rabbitmq-java-client/issues/411) > > ## Connection recovery runs into timeouts when using NIO > > GitHub issue: [#413](https://github-redirect.dependabot.com/rabbitmq/rabbitmq-java-client/issues/413) > > ## Provide factories to create NIO artefacts > > GitHub issue: [#410](https://github-redirect.dependabot.com/rabbitmq/rabbitmq-java-client/issues/410) > > ## 4.9.0 > This is a maintenance release with 2 new features and a bug fix. All users of the 4.x.x and 3.6.x series are encouraged to upgrade to this version. > > # Changes between 4.8.3 and 4.9.0 > > ## Add traffic listener > > GitHub issue: [#411](https://github-redirect.dependabot.com/rabbitmq/rabbitmq-java-client/issues/411) > > ## Connection recovery runs into timeouts when using NIO > > GitHub issue: [#413](https://github-redirect.dependabot.com/rabbitmq/rabbitmq-java-client/issues/413) > > ## Provide factories to create NIO artefacts > > GitHub issue: [#410](https://github-redirect.dependabot.com/rabbitmq/rabbitmq-java-client/issues/410) > > ## 5.5.0.RC1 > This is a pre-release for 5.5.0, a maintenance release with 2 new features and a bug fix. All users of the 5.x.x series are encouraged to test this version. > > # Changes between 5.4.0 and 5.5.0.RC1 > > ## Add traffic listener > ></table> ... (truncated) </details> <details> <summary>Changelog</summary> *Sourced from [amqp-client's changelog](https://github.com/rabbitmq/rabbitmq-java-client/blob/v5.5.1/release-versions.txt).* > RELEASE_VERSION="5.5.1" > DEVELOPMENT_VERSION="5.5.2-SNAPSHOT" </details> <details> <summary>Commits</summary> - See full diff in [compare view](https://github.com/rabbitmq/rabbitmq-java-client/commits/v5.5.1) </details> <br /> [](https://dependabot.com/compatibility-score.html?dependency-name=com.rabbitmq:amqp-client&package-manager=gradle&previous-version=3.5.3&new-version=5.5.1) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- **Note:** This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit. You can always request more updates by clicking `Bump now` in your [Dependabot dashboard](https://app.dependabot.com). <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme Additionally, you can set the following in the `.dependabot/config.yml` file in this repo: - Update frequency (including time of day and day of week) - Automerge options (never/patch/minor, and dev/runtime dependencies) - Pull request limits (per update run and/or open at any time) - Out-of-range updates (receive only lockfile updates, if desired) - Security updates (receive only security updates, if desired) Finally, you can contact us by mentioning @dependabot. </details>
For compatibility with OS X 10.11
Fixes #402