1
votes

I have a java servlet app (.war). The app itself is stateless and does only computations. It exposes its functionality via a REST API (implemented using Jersey 2). I am deploying the app on Cloud Foundry with several instances, the result however is that all requests are forwarded to ONLY 1 instance and its always the same one.

The app has a route and I am able to send requests to a particular instance using the X-CF-APP-INSTANCE header, but I would like my instances to balance themselves.

According to Cloud Foundry docs the gorouter should use a round-robin strategy when choosing which instance should serve the request. Am I missing something in the configuration or has anyone experienced behavior like this?

1
What is a size of request batch you used? Have you ran a batch of requests, say 20, 40, or 100 and see how which app instance handles them? What app instance id do you see in the log? - K.AJ
Load balancing should happen automatically. The main reason it would not is if you're using sessions. If JSESSIONID is set, you'll end up with sticky sessions and requests will go to the same app instance. How are you sending requests to the app? Can you try something like curl to send requests? This won't maintain a session by default, so it should round-robin across all app instances. Also, check the verbose output of curl -vv and see if the server is trying to set a cookie for JSESSIONID. - Daniel Mikusa
First - thanks for the hints. I definitely have a problem with load balancing. No matter how I send the requests (curl, swagger, jmeter, browser rest extensions) they always go to the same instance. "cf logs" confirms that and I could see either [APP/PROC/WEB/0] or [APP/PROC/WEB/1] for instance 0 or 1. I am able to address individual instances using X-CF-APP-INSTANCE header... - Yordan Boev

1 Answers

0
votes

The problem between the two apps was using Jersey's Client with http connection pool (PoolingHttpClientConnectionManager). I created the Client object once at the start as a Spring Bean and have it configured to take free connections from the pool. Removing the pool from the ClientConfig and using freshly created Client objects resulted in the requests being properly load balanced.