Jersey client requests issues on Java EE

Question

I am using Weblogic 12.2.1 and the built in Jersey client 2.21.1 to make a batch of https requests to a remote system every couple of hours.
For this I have a @Singleton bean with a @Scheduled method which gets executed by Weblogic at certain times. So on every execution of the @Scheduled method I'm making several https calls one after another. All requests are synchronous.

The problem is that for some reason the next request is sent with one minute delay after the previous (according Wireshark output). Jersey's invoke call is blocking. Responses come immediately. There is no problem with the remote system.

The same code for sending the requests when executed in a JUnit test (plain java) has no delay. All requests pass immediately. So maybe is something with the Weblogic container.
Anyone with similar issue?

Answer 1

Actually when I changed the default HttpUrlConnectorProvider in the client with ApacheConnectorProvider there were no more delays between requests. Indeed what the Jersey documentation states about this is:

...in complex environments (such as application servers), where some poolable connections might exist before your application even bootstraps, this approach is not 100% reliable and we recommend using a different client transport connector, such as Apache Connector.

But yet again there arises another problem if you want to use the client's multipart feature. On this the docs say:

Warning

Be aware of using other than default Connector implementation. There is an issue handling HTTP headers in WriterInterceptor or MessageBodyWriter. If you need to change header fields do not use nor ApacheConnectorProvider nor GrizzlyConnectorProvider neither JettyConnectorProvider. The issue for example applies to Jersey Multipart feature that also modifies HTTP headers.

And finally I found myself in a situation where I have to choose ApacheConnector (fast requests) with no multipart or slow requests with multipart. Funny isn't it?

I guess I should spend more time on researching for other restful clients which are actually working on Java EE environments.