Platform Engineering: Enhance the developer experience, establish secure environments, automate self-service tools, and streamline workflows
The dawn of observability across the SDLC has fully disrupted standard performance monitoring and management practices. See why.
Innovating and building products at the intersection of digital media, online marketing and display advertising. A highly creative, talented, engineer with expertise in digital media and online advertising platforms. Throughout my career I have worked across various geographical areas (Europe, America) and helped companies develop and scale solutions in the online advertising space. Extensive hands-on experience across the full stack: front end to back end to data layer with expertise in distributed systems, scaling and low latency. Well versed with cloud centric solutions such as Amazon Web Services. I have a diverse skill-set, including architecture, implementation, maintenance and devops. In addition, I am both a team player and a natural leader who is able to build, train and motivate teams to produce exceptional results. twitter: @liviutudor
Stats
| Reputation: | 285 |
| Pageviews: | 75.5K |
| Articles: | 3 |
| Comments: | 4 |
Comments
Jun 26, 2018 · Lindsay Burk
I think the idea of the Java EE standards is exactly to allow you to use whatever other frameworks you need , including RxJava -- or for that matter any other multi threading library.
You are right however about the ThreadLocal being very specific to Jersey. And my whole point was that even using Jersey, the issue only surfaces when injecting variables via a @Context annotation -- strangely enough having a regular servlet with a service() method does not use a ThreadLocal and does not exhibit this issue, so one CAN actually pass the request method around.
Jun 26, 2018 · Lindsay Burk
Java EE only talks about resources such as EJB, data sources etc -- there is nothing there about the Request (or Response for that matter) objects. Same applies to the
And the Servlet spec, all the discussions around threading is to stress the fact that your service method CAN be called from multiple threads -- however the Request/Response pair is passed in as parameters, so again, no mention as to why one could not pass any of those to another thread. If anything, the fact that they put so much thought into the threading model of the servlets (and therefore JSPs and the likes) would suggest exactly the fact that it's perfectly fine to send this around.
Last but not least, read again my article -- this issue only occurs due to the usage of `@Context` annotation, and specifically on top of Jersey. Doing the same via standard servlets works perfectly fine. So the issue is with the implementation of the JAX-RS specification specifically.
Jun 26, 2018 · Lindsay Burk
I am happy to accept ignorance on my side but as far as I recall Java EE talks about RESOURCE management not about things such as the request itself.
I would love to learn more though if my understanding is wrong -- any links?
Jun 26, 2018 · Lindsay Burk
I disagree: it's a common pattern to create data in one thread and pass it for processing to another thread. The whole immutability concept got a lot of attention due to this pattern, so if my data is immutable then I should be able to pass it to any thread I want.
And that's exactly what I am trying to do here: pass a request object for reading only purposes to another thread. It just so happens that Jersey in particular uses ThreadLocal's which creates the problem. There might be other frameworks impementing JAX-RS which suffer from this but this is definitely NOT a standard of the JAX-RS extension.