getOrElseUpdate and http context
See original GitHub issueI am having the following issue. When I use this java method I am loosing the http context.
Reporting a bug?
- Version of play-redis: 1.6.0
- Version of Scala 2.12
- Version of Play 2.6.6
- Describe the environment if applies (usually in cloud etc.)
- Describe the expected behavior: it should return a
CompletionStage
with the http.context
Issue Analytics
- State:
- Created 6 years ago
- Comments:14 (3 by maintainers)
Top Results From Across the Web
Play Framework 2.6 Java Async Session and ... - Stack Overflow
The lookUpUser function throws an error of : java.lang.RuntimeException: There is no HTTP Context available from here. Any help would be ...
Read more >Http.Context (Play 2.6.18)
Creates a new HTTP context, using the references provided. Context(java.lang.Long id, play.api.mvc.RequestHeader header, Http.Request request, ...
Read more >playframework/playframework - Gitter
In Java/Play 2.4.3 we could use the the ThreadLocal ( Http.Context.current().request() ), but in Scala, i'm confused as to how to do it....
Read more >com.google.inject.Scopes.isCircularProxy java code examples ...
public <T> T getOrElseUpdate(final Key<T> key, final Supplier<T> fallback) { final T value ... @Override public T get() { final Http.Context currentContext ...
Read more >NoClassDefFoundError: org/w3c/dom/Node upon portlet start ...
getOrElseUpdate (WebAppContext.scala:96) at org.orbeon.oxf.externalcontext.OrbeonWebApp$class. ... at org.eclipse.equinox.http.servlet.internal.context.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Great. I also believe that the workaround is good but It would be cool if we can fix this topic from the implementation of RedisCache 😃
The context is stored on the thread local. When you do something like:
CompletableFuture.supplyAsyn(()-> doSomething())
you are executing a task on the common-fork-join and leaving behind the akka dispatcher from play. That means that if you later do something like:promise.thenApply(something -> something + request().getHeader("myheader"))
you will get aRuntimeException
since the methodrequest()
is trying to get the Http context and you don’t have it anymore.Play offers you a class called
HttpExecutionContext
that will allows you execute a asynchronous task in the same akka dispatcher and keeping your http context available as explained here. Even though you are still in the same executor, you might jump to a different thread, so you still need to move the http context from the previous thread to the new one.In scala you don’t have these problems, but if you are doing a java version you still need to be aware of this topic. In the class
JavaRedis
you are doingFuture.sequence()
and implicitly you are passing your execution context. When you do this, theCompletionStage
that you return does not have the http context anymore. Still, scala play api offers you a nice utility method called fromThread that would allow you to assign the context to the new thread of the executor. My knowledge on scala ends here, so I hope you have enough information to solve the problem from there.