On 26/04/13 09:48, Sergey Beryozkin wrote:
Hi,
On 26/04/13 00:11, Adar Dembo wrote:
Thanks for the suggestion.
Will using the WebClient in this way open a socket over the host's
loopback interface? Since I'm keeping a database transaction open (via
Hibernate) during this time, it's important that 1. the latency in the
batch calls be minimal, and 2. the calls themselves be made by the same
thread as the one that serviced the batch endpoint. Can I configure the
WebClient in some way to get these guarantees?
I'm not sure we can have the current thread which invokes on the
endpoint run that endpoint's own external call completely.
Actually, if we get WebClient use CXF's Async HTTP Conduit (Apache HTTP
Client based), using WebClient#async switch to JAX-RS 2.0 AsyncInvoker
(starting from CXF 2.7.0), then I guess we won't have a single thread
involved, otherwise it should be a single thread. Dan, clarify please if
it is not quite the case.
I don't think we have any control over what happens at the socket level,
unless... Are you dealing with the the same host outbound calls ? If yes
- try using the local transport:
https://cwiki.apache.org/confluence/display/CXF20DOC/JAXRS+Testing#JAXRSTesting-LocalTransport
http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/JAXRSLocalTransportTest.java
Finally, on the server, try using JAX-RS 2.0 AsyncDispatch (best from
CXF 2.7.4), that may help on its own, I'll work on documenting all 2.0
features asap.
Sorry, meant AsyncResponse:
https://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/container/AsyncResponse.html
Sergey
