Hi I have a complex flow where my payload is getting modified along with original payload. In order to get the original payload I am storing the initial payload in a mule session variable so that I can use that variable(original payload) down the flow. This process is working but my concern is my mule session variable thread safe?
I tried choosing invocation,outbound scope but I found that variable value become null down the flow after some processing and transformation.
Any input would be greatly appreciated. Thanks
The mule message is processed by one thread at a time, so variables or properties (any scope) in the mule message don't need to be thread-safe. Invocation scope should be enough if you want to use a property in a single flow.
Apparently, the session variables are not thread safe. I used a session variable in a flow that has splitter and aggregator for parallel execution of a piece of code (which modifies the same session variable). Found that it overwrites the data inside the splitter thread!
Session variable is meant for storing values which need to be reference after the flow passes through a transport barrier which could be any connector. Within the same flow session variable is thread safe.
Related
We are using #Async for multithreading. Untill each multithreading method i can see values for RequestContextHolder.getRequestAttributes().
But when i debug inside the method i'm getting request attributes as NULL.
Any thoughts?
To get around this issue we created a ContextAwareRunnable Object that was pre-populated with the current requestHolder, securityContextHolder, etc, so that all spawned threads would be able to execute as if it were running in the main thread.
By default ThreadLocal variable is used as holder for request attributes. That means that only single thread which handles entire https request is able to access request attributes. In contrast #Async methods are processed by threads from a separate thread pool so they can't access the attributes.
However there is one more InheritableThreadLocal variable which could be used as request attributes holder instead for default one. You can enabled it by setting threadContextInheritable property to true in DispatcherServlet or RequestContextFilter.
Take a look at implementation of RequestContextHolder for more details.
I have a Servlet which calls some business methods and have a requirement to generate a unique transaction id for each and every request this servlet process and we need to pass this transaction id to the business methods.
One solution would be passing this transaction id as a parameter to all the business methods. But this is not a good solution as the code is redundant and unnecessary.
You could add it as a thread local variable in the servlet and access it for anywhere else. Each incoming request would spawn a new thread and thread local variable would be local to that thread alone
I have solved this by use of ThreadLocal.
Thread Local can be considered as a scope of access, like a request scope or session scope. It’s a thread scope. You can set any object in Thread Local and this object will be global and local to the specific thread which is accessing this object. I have referred this article to fix this.
Been trying to extract a value from the response data of a thread group,store it in a variable use the variable in the subsequent thread group. Would be great if someone provides insights on how to proceed.
Variables are local to a thread. Use properties as they're common to all threads.
From here:
Properties are not the same as variables. Variables are local to a thread; properties are common to all threads, and need to be referenced using the __P or __property function.
Use __setProperty() function to convert JMeter Variable to JMeter Property in one thread group
Use __property() function to access previously set property value in another thread group(s)
See Knit One Pearl Two: How to Use Variables in Different Thread Groups article for detailed explanation
I am using approach from the "Accessing scoped proxy beans within Threads of" answer. However I am seeing rare deadlocks involving RequestAttributes object. The main reason of the deadlock is between the synchronized (this.sessionAttributesToUpdate) statement in the object and servlet session hash-map. Normally the instances of the object are created for each request, so they don't clash, but if I pass the object to another thread to use the session beans, the same object is used and it causes deadlock sometimes.
The deadlock happens if current http request is not completed while the another thread starts using a session bean passed with RequestContextHolder.setRequestAttributes.
I think this guy mentions the same problem, but his question is unanswered: Session scoped bean encountering deadlock.
So, any ideas how to avoid the deadlock?
Here's an answer that provides alternative solution considering the objective is to calculate something in background while user is navigating pages.
Possibility 1:
Create a service bean with processing method that is annotated with #Async (http://static.springsource.org/spring/docs/3.0.x/reference/scheduling.html) that returns a result of computation in a Future object. Store the Future object in the session. Access the result in subsequent requests through Future object if task is completed. Cancel the the task via Future.cancel if session is to be destroyed before task is completed.
Possibility 2:
Take a look if new features of Spring 3.2 and Servlet 3.0 async processing can help you:
http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/mvc.html#mvc-ann-async
Possibility 3:
Emulate a task queue. Create a singleton service that can put objects to structure like ConcurrentMap where key would be some job id (you can than store key into session) and value the result of background processing. Background thread would then store objects there (this is perhaps not much better than accessing session directly, but you can make sure it's thread safe).
Are the threadlocals variables global to all the requests made to the servlet that owns the variables?
I am using resin for the server.
Thanks for awnser.
I think I can make my self more clear.
The specific Case:
I want to:
initialize a static variable when the request starts the execution.
be able to query the value of the variable in the further executions of methods called from the servlet in a thread safety way until the request ends the execution
Short answer: Yes.
A bit longer one: This is how Spring does its magic. See RequestContextHolder (via DocJar).
Caution is needed though - you have to know when to invalidate the ThreadLocal, how to defer to other threads and how (not) to get tangled with a non-threadlocal context.
Or you could just use Spring...
I think they are global to all requests made with that specific thread only. Other threads get other copies of the thread-local data. This is the key point of thread-local storage:
http://en.wikipedia.org/wiki/Thread-local_storage#Java.
Unless you check the appropriate option in the servlets config, the servlet container will use your servlet with multiple threads to handle requests in parallel. So effectively you would have separate data for each thread that's up serving clients.
If your WebApplication isn't distributed (runs on multiple Java Virtual Machines), you can use the ServletContext object to store shared data across requests and threads (be sure to do proper locking then).
Like Adiel says, the proper way to do this is probably to use the request context (i.e. HttpServletRequest), not to create a ThreadLocal. While it's certainly possible to use a ThreadLocal here, you have to be careful to clean up your thread if you do that, since otherwise the next request that gets the thread will see the value associated with the previous request. (When the first request is done with the thread, the thread will go back into the pool and so the next request will see it.) No reason to have to manage that kind of thing when the request context exists for precisely this purpose.
Using ThreadLocal to store request scoped information has the potential to break if you use Servlet 3.0 Suspendable requests (or Jetty Continuations)
Using those API's multiple threads process a single request.
Threadlocal variables are always defined to be accessed globally, since the point is to transparently pass information around a system that can be accessed anywhere. The value of the variable is bound to the thread on which it is set, so even though the variable is global, it can have different values depending on the thread from which it is accessed.
A simple example would be to assign a user identity string to a thread in a thread local variable when the request is received in the servlet. Anywhere along the processing chain of that request (assuming it is on the same thread in the same VM), the identity can be retrieved by accessing this global variable. It would also be important to remove this value when the request is processed, since the thread will be put back in a thread pool.