ResteasyProviderFactory and the JAX-RS api RuntimeDelegate cache
by Alessio Soldano
Hi,
while working on the changes for
https://issues.jboss.org/browse/RESTEASY-1531 , I figured out that we
possibly have a general issue with the javax.ws.rs.ext.RuntimeDelegate
cache mechanism. That class basically has a static cachedDelegate which
is used to store the first resolved implementation of RuntimeDelegate
and offer it to any following request.
The problem is that RESTEasy implementation of RuntimeDegate,
ResteasyProviderFactory, comes with many data (look at its field
members) that relates to a specific application / deployment. Sharing an
instance among different application does not seem correct.
The ResteasyDeployment class is also setting and clearing that cache
value using ResteasyProviderFactory:setInstance and
ResteasyProviderFactory: clearInstanceIfEqual methods which I believe
results in a mess in-container, with multiple deployments going over
others (the clear method is called upon undeployment).
The problem seems to be mitigated by the fact that many users simply go
and create a new ResteasyProviderFactory using our proprietary api,
instead of getting it through standard JAX-RS api.
To deal with a similar problem in my branch for RESTEASY-1531 I've
basically duplicated the resolution mechanism within RESTEasy and
bypassed the cache stuff, but the problem is still there for pure JAX-RS
api users.
Am I missing something here? Any thoughts / idea?
Cheers
Alessio
7 years, 5 months
Chinese text was wrong transfered
by Jianhua Zhang
hi,
I have a interface need post two parameters (long string, cannot use get or
path params), so i choose FormParam annotation:
@Path(value="/song/search")
@POST
@Consumes("application/x-www-form-urlencoded;charset=utf-8")
@Produces("application/json;charset=utf-8")
ServiceResult getSongList(@FormParam("songs") String songsInfoJson,
@FormParam("clientid") String clientId);
and i use reasteasy-client to call this interface, post paramters like
below:
songs:[{"album":"Sunshine
光明随想","title":"婚礼场面舞","artist":"金元辉;","id":"fb49e3de456bee952c8c9b3d3d8977c4","fileName":"100455298.mp3","disk":-1,"duration":112431,"sid":-1,"size":1694184,"albumSid":-1,"albumId":-1},{"album":"","title":"幻想即兴曲","id":"934fdf53d47304e30b587cfae7219136","fileName":"73864517.mp3","disk":-1,"duration":376058,"sid":-1,"size":6018215,"albumSid":-1,"albumId":-1},{"album":"","title":"谷粒飞舞","id":"bffdd1bfa0bfedaf7690540221fee91e","fileName":"73891360.mp3","disk":-1,"duration":145658,"sid":-1,"size":2331813,"albumSid":-1,"albumId":-1}]
clientid:test123
when server side received, the songsInfoJson content changed to like below:
[{"album":"Sunshine å…‰æ˜Žéš æƒ³","title":"婚礼场é
¢èˆž","artist":"金元辉;","id":"fb49e3de456bee952c8c9b3d3d8977c4","fileName":"100455298.mp3","disk":-1,"duration":112431,"sid":-1,"size":1694184,"albumSid":-1,"albumId":-1},{"album":"","title":"幻想å
³å…´æ›²","id":"934fdf53d47304e30b587cfae7219136","fileName":"73864517.mp3","disk":-1,"duration":376058,"sid":-1,"size":6018215,"albumSid":-1,"albumId":-1},{"album":"","title":"谷粒飞舞","id":"bffdd1bfa0bfedaf7690540221fee91e","fileName":"73891360.mp3","disk":-1,"duration":145658,"sid":-1,"size":2331813,"albumSid":-1,"albumId":-1}]
========================
i find the problem is the charset is not set in http request header.
org.jboss.resteasy.client.jaxrs.internal.proxy.processors.invocation.FormParamProcessor
create the new form entity, for this entity, the media type is hard code
as: APPLICATION_FORM_URLENCODED_TYPE = new MediaType("application",
"x-www-form-urlencoded"), the consumes annotaion doesn't take effect.
form = new Form();
target.getInvocation().setEntity(Entity.form(form));
org.jboss.resteasy.client.jaxrs.internal.ClientInvocation
public void setEntity(Entity entity)
{
...
Object ent = entity.getEntity();
setEntityObject(ent);
this.entityAnnotations = entity.getAnnotations();
Variant v = entity.getVariant();
//header set
headers.setMediaType(v.getMediaType());
headers.setLanguage(v.getLanguage());
headers.header("Content-Encoding", v.getEncoding());
...
}
if manual change x-www-form-urlencoded to
x-www-form-urlencoded;charset=utf-8, the problem will save.
is this a bug or anything wrong with me.
--
Jianhua Zhang
iFLYTEK
7 years, 6 months
RESTEasy asynchronous processing with @Suspended -- actually synchronous?
by Steven Schlansker
[ apologies for the rampant cross-posting, it looks like I might have been sending this to old mailing lists, and getting lost in the void? ]
Hello resteasy-dev,
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)
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
7 years, 6 months
RESTEASY-1512 and jboss-modules
by Ron Sigal
I've been working on bringing the content of jboss-modules into line
with wildfly 10.1.0.Final, and I've run into a problem. The yaml
integration tests are failing, and it's because yaml's module.xml has
> <properties>
> <property name="jboss.api" value="private"/>
> </properties>
I've found some discussion
(http://wildfly-development.1055759.n5.nabble.com/what-is-jboss-api-privat...)
where David Lloyd says
> On 12/18/2012 10:37 AM, Bill Burke wrote:
> > I've been doing multiple searches trying to figure out exactly what
> > jboss.api=private in modules.xml means.
> >
> > Does it exclude/filter all classes under org.jboss.* from being
> imported
> > to your deployment?
>
> No, it's purely for EAP, so customers know that they're on their own if
> they import private or unsupported modules into their deployments.
1, I'm not sure how to handle this. Maybe the right thing to do is
change the yaml integration tests to import resteasy-yaml-provider.
2. Oddly, there are several other modules, e.g., resteasy-cdi,
resteasy-jsapi, ..., that are also marked private and they aren't
causing any failures.
Thoughts?
-Ron
--
My company's smarter than your company (unless you work for Red Hat)
7 years, 6 months
PR #965
by Alessio Soldano
Folks,
Tomaz has sent PR https://github.com/resteasy/Resteasy/pull/965 few
minutes ago. It basically upgrade many dependencies and fix few things
in the build to make it more jdk9 friendly. Besides that we eventually
have a single jetty dependency in the whole build and the few remained
jetty based tests are now using arquillian.
Overall the changes look interesting and the build is passing on Travis
CI. I'm thinking about merging the PR tomorrow or so, after having
created few JIRAs for the component upgrades, and then cut a 3.1.0.CR2
release. Any thought / concerns ?
Cheers
Alessio
7 years, 6 months
