5:05 a.m.
Hello resteasy users,
I am trying to use the new JAX-RS 2.0 @Suspended AsyncResponse mechanism to write
a service that expects many idling connections (awaiting an event via long-poll),
and therefore seems like a good candidate for asynchronous responses, so as not
to use a large number of waiting threads.
The resource code is very simple:
@GET
@Produces(MediaType.APPLICATION_JSON)
public void watchForChanges(
@Suspended AsyncResponse asyncResponse,
@QueryParam("since") long since)
{
controller.watchForChanges(since, asyncResponse::resume);
}
The intent is that watchForChanges places the (inferred) Consumer<ResponseObject> on
a queue,
and returns immediately. Later on a background thread comes by and completes the
request.
However, when testing with say 20 clients, it sure looks like the end result is still a
thread per request model:
"qtp1718322084-43" - Thread t@43
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <3537ebd5> (a java.util.concurrent.CountDownLatch$Sync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at
org.jboss.resteasy.core.SynchronousExecutionContext$SynchronousAsynchronousResponse.initialRequestThreadFinished(SynchronousExecutionContext.java:127)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:411)
at
org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:247)
at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:225)
at
org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:62)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1676)
<snip Jetty handler / filter chain>
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:319)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:253)
at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148)
at
org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
The concept of a "SynchronousAsynchronousResponse" and implementation of in
particular SynchronousDispatcher#invoke seem to be totally not what I want:
/**
* Callback by the initial calling thread. This callback will probably do
nothing in an asynchronous environment
* but will be used to simulate AsynchronousResponse in vanilla Servlet
containers that do not support
* asychronous HTTP.
*
*/
request.getAsyncContext().getAsyncResponse().initialRequestThreadFinished();
What am I doing wrong? How do I get truly asynchronous processing?
This is with RESTEasy 3.0.18 running on Jetty 9.3.11
Thanks for any advice,
Steven