search

arquillian / arquillian-cube

Control (docker, kubernetes, openshift) containers in your tests with ease!
http://arquillian.org/arquillian-cube/
117 stars 98 forks source link

Docker Java transport selection #1252

Open tommyb82 opened 1 year ago

tommyb82 commented 1 year ago
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 (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
  1. 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));
  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.

TheOnlyAl commented 1 year ago

Hi there.

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.

https://github.com/arquillian/arquillian-cube/compare/master...TheOnlyAl:arquillian-cube:docker-java-httpclient5#files_bucket

If someone would like to use parts of the code or if I should create a pull request with the changes, then feel free to come back to me.

gtudan commented 1 year ago

Having the same issue - adding the old javax-spec to the Testsuite kept my tests running. But a different transport would be great