You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Question / enhancement suggestion (have searched SO for info)
Is it currently possible to configure Arq Cube to initialize a Docker client that uses a transport other than the deprecated Jersey client library? We are facing some (intermittent) issues with it and would like to switch the underlying transport to https://github.com/docker-java/docker-java/blob/master/docs/transports.md#apache-httpclient-5 , but having stepped through the code (starting with org.arquillian.cube.docker.junit.rule.ContainerDslRule), it appears to be hard-wired (via org.arquillian.cube.docker.impl.util.DefaultDocker to initialize the Docker client without a dedicated HTTP client, thereby falling back to Jersey.
Desired Behaviour
Provide some means of selecting the transport used by the underlying Docker Java lib, or change the default to Apache HttpClient 5 which is stable and will be in LTS.
Current Behaviour
Arquillian Cube via top-level ContainerDslRule class will only initialise Docker Java client using Jersey HTTP client library.
Steps To Reproduce
Create a basic container test with the container class rule to stop and start a local container for use in tests:
@ClassRule
public static ContainerDslRule container = new ContainerDslRule("my-image:latest", container").withAwaitStrategy(AwaitBuilder.logAwait("Service started", 10, 1));
Run tests, debug and observe that Docker Java client falls back to Jersey HTTP client (with occasional deadlock scenario as described below)
Additional Information
The specific issue we are facing is an intermittent deadlock scenario reading container logs for an expected 'ready' statement (from a DB container), which sometimes resolves and container tests then proceed and finish successfully (albeit after several minutes) and sometimes hangs indefinitely requiring it to be killed and container stopped / removed manually. I have traced this through into the Docker Java client code and am still seeking the exact cause - but wanted to raise the question of transport client switching here.
The text was updated successfully, but these errors were encountered:
I also had problems with the currently underlying transport which lead to errors using arquillian-cube with tests based on the Jakarta EE Api. Because of this, I created an POC implementation which uses the suggested Apache HttpClient 5 transport.
Issue Overview
Question / enhancement suggestion (have searched SO for info)
Is it currently possible to configure Arq Cube to initialize a Docker client that uses a transport other than the deprecated Jersey client library? We are facing some (intermittent) issues with it and would like to switch the underlying transport to https://github.com/docker-java/docker-java/blob/master/docs/transports.md#apache-httpclient-5 , but having stepped through the code (starting with
org.arquillian.cube.docker.junit.rule.ContainerDslRule
), it appears to be hard-wired (viaorg.arquillian.cube.docker.impl.util.DefaultDocker
to initialize the Docker client without a dedicated HTTP client, thereby falling back to Jersey.Desired Behaviour
Provide some means of selecting the transport used by the underlying Docker Java lib, or change the default to Apache HttpClient 5 which is stable and will be in LTS.
Current Behaviour
Arquillian Cube via top-level
ContainerDslRule
class will only initialise Docker Java client using Jersey HTTP client library.Steps To Reproduce
Additional Information
The specific issue we are facing is an intermittent deadlock scenario reading container logs for an expected 'ready' statement (from a DB container), which sometimes resolves and container tests then proceed and finish successfully (albeit after several minutes) and sometimes hangs indefinitely requiring it to be killed and container stopped / removed manually. I have traced this through into the Docker Java client code and am still seeking the exact cause - but wanted to raise the question of transport client switching here.
The text was updated successfully, but these errors were encountered: