5

At our company we are developing a quasi standard REST service running within wildfly 10.1. Each request owns a tenant header which will be intercepted by a filter and the tenant information will be stored within a @RequestScoped bean for later use inside the rest or service layer. So far so good. Now we found out that some code inside a service was using a Java 8 parallel stream and failed to use the @RequestScoped bean to lookup the current tenant. We verified this several times. Using non parallel streams solved this issue for us.

Is this normal behaviour? We are really confused that using standard Java 8 features breaks our expected container behaviour..

Are there any other such culprits we need to care of?

Gerrit
  • 365
  • 1
  • 3
  • 19
  • 2
    Related: http://stackoverflow.com/questions/36338505/completablefuture-parallelstream-in-javaee-app-server – assylias Apr 25 '17 at 10:01

1 Answers1

5

It seems than parallel will spawn threads even in a managed context.

However RequestScoped is handled using a ThreadLocal (We are here still in the good old multi-threaded model ie. an http Request = 1 thread).

So yes it's normal

Community
  • 1
  • 1
Gab
  • 7,869
  • 4
  • 37
  • 68