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.
Sergey
On Thu, Apr 25, 2013 at 4:47 AM, Sergey Beryozkin <[email protected]
<mailto:[email protected]>> wrote:
Missed the links this time:
[1]
https://cwiki.apache.org/__confluence/display/CXF20DOC/__JAX-RS+Client+API#JAX-__RSClientAPI-__ConfiguringHTTPclientsinSpring
<https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Client+API#JAX-RSClientAPI-ConfiguringHTTPclientsinSpring>
[2]
https://cwiki.apache.org/__confluence/display/CXF20DOC/__JAX-RS+Client+API#JAX-__RSClientAPI-ThreadSafety
<https://cwiki.apache.org/confluence/display/CXF20DOC/JAX-RS+Client+API#JAX-RSClientAPI-ThreadSafety>
On 25/04/13 12:46, Sergey Beryozkin wrote:
Hi, no problems, I replied earlier, copying here just in case too:
On 25/04/13 12:45, Adar Dembo wrote:
(apologies if you're receiving this twice; the first time I
sent it I
wasn't subscribed to the list, so I think it got dropped)
My application uses JAX-RS to build its external API. I
think the
implementation is as you'd expect: requests are dispatched
to the
appropriate resource, based on the @Path, @GET, @POST,
@DELETE, etc.
annotations.
I'm trying to build a "batch" endpoint for this API. The
idea is that the
endpoint would have a single resource, which, when it gets a
POST, would
create a new database transaction, dispatch to a number of other
endpoints,
and commit the transaction. Any dispatch failures would roll
back the
transaction. The body of the POST would contain information
on what to
dispatch (i.e. it'd be a list where each item is an HTTP
method, a
URL, and
a body).
My problem: how do I redispatch from inside my batch
endpoint? I'd
like to
call into CXF for each batch list item, otherwise I have to
do all the
argument marshaling myself. Put another way, I want to give
CXF an HTTP
method, a URL, and a body, and have it call the appropriate
resource
in the
appropriate way for me. How do I do that?
I think you can inject a single CXF WebClient instance [1] into the
endpoint's root resource, with a 'threadSafe' flag set to 'true' and
some base path set too, and then adjust it use one of its generic
invoke() methods. This should be the most effective option as
the actual
client instance will be set up/initialized only once, though at
the cost
of having a thread-local map utilized on the client side.
Or you can try creating clients dynamically, example:
JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean();
bean.setAddress(address);
WebClient wc = bean.createWebClient();
Response r = wc.post(body);
TransactionItem item = r.readEntity(TransactionItem.__class);
...
HTH, Sergey
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
