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
Am I missing something here? Any thoughts / idea?
[ 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? ]
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:
public void watchForChanges(
@Suspended AsyncResponse asyncResponse,
@QueryParam("since") long since)
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
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <3537ebd5> (a java.util.concurrent.CountDownLatch$Sync)
<snip Jetty handler / filter chain>
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.
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,
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
> <property name="jboss.api" value="private"/>
I've found some discussion
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
> > 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.
My company's smarter than your company (unless you work for Red Hat)
While searching for some existing jmh tests I found https://issues.apache.org/jira/browse/CXF-6189 Improve memory usage of UrlUtils. Sergey says there "I recall awhile back I saw RestEasy and Oltu using the same code for encoding/decoding".
Discussion on CXF-6189 is quite interesting, fixed class in CXF is https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/c...
Sergey's comment made me wondering which util class he is referring to.
Naive approach with https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/... seems to be incorrect.
My bet would be on https://github.com/resteasy/Resteasy/blob/master/resteasy-jaxrs/src/main/...
grep -l URLDecoder . -R | grep "src/main/java" | sort
I think memory footprint changes done as part of https://issues.apache.org/jira/browse/CXF-6189 could be hopefully used as an inspiration for changes in RESTEasy.
I miss expertise with the codebase whether CXF-6189 changes are relevant for us and where it could be applied.
Basically searching for volunteer before I force push myself to forget about it.
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 ?