java rest client gets Remotely closed error on connection to kubernetes minikube service

8/4/2017

I'm developing a service that will run in Kubernetes. For functional testing of this service our tests will deploy the service to minikube running on a laptop.

In the most basic test the java client just pings a health check endpoint of the service. The java client uses Jersey and creates the client simply like:

import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
..
 private static final Client CLIENT = ClientBuilder.newClient();

The request fails with;
2017-08-04 13:57:55.202 WARNING [PingTest] Remotely closed
2017-08-04 13:57:55.206 INFO [system.err] javax.ws.rs.ProcessingException: Remotely closed
2017-08-04 13:57:55.207 INFO [system.err]     at org.glassfish.jersey.grizzly.connector.GrizzlyConnector.apply(GrizzlyConnector.java:260)
2017-08-04 13:57:55.207 INFO [system.err]     at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:252)
2017-08-04 13:57:55.208 INFO [system.err]     at org.glassfish.jersey.client.JerseyInvocation$1.call(JerseyInvocation.java:684)
..

But I can invoke the same endpoint running in minikube directly in curl or from Postman.

The requests sent from the 3 different clients are essentially the same (except for the user-agent):

--POSTNAME--
GET /20170101/health HTTP/1.1
cache-control: no-cache
Postman-Token: f899c540-e93a-479b-9e8b-c58e356140d7
User-Agent: PostmanRuntime/6.2.5
Accept: /
Host: localhost:31081
accept-encoding: gzip, deflate
Connection: keep-alive

--CURL--
GET /20170101/health HTTP/1.1
Host: localhost:31081
User-Agent: curl/7.54.0
Accept: /

--JAVA TEST--
GET /20170101/health HTTP/1.1
User-Agent: Jersey/2.24.1 (Async HTTP Grizzly Connector 2.24.1)
Host: localhost:31081
Connection: keep-alive
Accept: /

Any ideas of why I can access the endpoint from curl or Postman but not from a java client?

-- tiwatso
java
jersey
kubernetes
minikube
rest

1 Answer

8/5/2017

Turns out to be a timing issue, there is a call back method meant to wait until the containers get to ready status before invoking the service endpoints but found a code path that bypassed the callback.

-- tiwatso
Source: StackOverflow