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
Related
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.
In JMeter I have a thread group and I want to control how many threads are run using a jmeter variable. In the thread group I'm setting Number of Threads equal to ${numThreads}. I have a setup thread group that has a bean shell sampler with the following (this always runs before the main test thread group):
vars.put("numThreads","5");
If I set numThreads in a user defined variables config element in the setup thread group it will use the correct number of threads. However I want to control it using a variable I defined in a bean shell sampler and it is not working. I can see the variable is being created and I can print the value in the log but when I use the bean shell sampler the thread group does not correctly create 5 threads (it creates 0 threads). The only thing I can think of is they both create variables but maybe the user defined config element creates it as an integer type? When I debug the type of the variable it shows as a string regardless of if it is set in a user defined parms config or bean shell sampler.
log.debug(vars.get("numThreads").getClass().getName()); // this prints java.lang.String for both
Why does the thread group not create the correct number of threads based on the bean shell variable?
Ok I figured it out. Looks like variables are thread specific and properties are global to the entire test. So setting a variable in the setup threadgroup was out of scope when my main thread group starts. Now Im setting a property in the setupgroup beanshell and using the following in the main threadgroup:
setup threadgroup beanshell:
props.put("threadCount","3");
In the main threadgroup I can use the following to start the correct number of threads:
${__P(threadCount)}
Still no idea why the user defined variables config element was working - it must generate properties rather than variables or something.
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.
I have many concurrent running http request serving threads. They will be creating an Object(? extends Object) for every request and save the object in a list.
Advice me some good data structure to implement this list.
I can't use ArrayList since it was not thread safe.
I dont like to use Vector - since its synchronized, it will make other threads to wait when one of the http thread was saving the object.
Also tried LinkedList, but there is data loss due to concurrent update.
Your variable would need to be atomic so that it can safely be updated by multiple threads (see java.util.concurrent.atomic). You could also use an AtomicInteger to keep track of the number of times the variable is updated.
But are you sure you want do this without explicitly controlling the update to a variable?
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.