How can I get the Thread Controller Name (i.e. 'Thread Group')?
In my test I have:
Thread Controller Name: 'Thread Group'
Thread Name: 'My Thread'
Thanks,
Take a look at the following JMeter Functions:
__threadGroupName() - returns the name of the Thread Group
__threadNum() - returns the number of the current thread
Related
I am trying to do setproperty across multiple threads in the same threadgroup, the postprocessor set new variable using setproperty, so that It can be accessed across multiple threads.
In Beanshell preprocessor, I'm having below line of code.
${__setProperty("url", "youtube")};
Under thread Group I'm having Beanshell post processor, having below one line in postprocessor.
${__setProperty("url", "google")};
under thread group, I have Http Sampler, in hostname field I have given ${__property(url)}.com
The Aim is, when it executes first time, the URL will be google.com and when first threads complete than
the URL becomes youtube.com
But the setProperty only set google, and the second one in postprocessor was not working.
Refer the below Image for details, it shows how I created the element in Jmeter.
enter image description here
Note: This was just a sample use case, but I have complex example, but answering to this question will help me to add the logic in complex script.
Thanks
So is the goal that the very first thread to complete will change the URL for all subsequently created threads?
My understanding of the documentation is that you can't change the value of a property inside the thread-group:
Properties can be referenced in test plans - see Functions - read a property - but cannot be used for thread-specific values.
(see http://jmeter.apache.org/usermanual/test_plan.html#properties)
My assumption is that each thread in a thread-group gets a copy of the properties. If you change the value of the property inside the thread group, then you are actually changing the copy for that particular thread. Since you are changing it in the post-processor, the thread is very likely just about to be disposed, resulting in your change being lost. After disposal a new thread is created but with the original value of the property.
So what you need to do is figure out how to change the value outside of the thread-group.
I have done something similar in my own tests whereby I am changing the value of a property in the middle of the test, and the value is picked up immediately by all of the active thread-groups, resulting in each new thread created from that point forward getting the new value. I am doing this by using the Beanshell Server: https://jmeter.apache.org/usermanual/best-practices.html#beanshell_server
In my specific case I use jenkins job that calls a shell-script which connects to the beanshell-service running on the local-host:
java -jar ${jmeter_home}/apache-jmeter-5.0/lib/bshclient.jar localhost 9000 ${test_plan_home}/update_Prop.bsh "${property}" "${value}"
where my update_prop.bash file is simply:
import org.apache.jmeter.util.JMeterUtils;
JMeterUtils.getJMeterProperties().setProperty(args[0],args[1]);
You would not need to use Jenkins or anything like that, though - if you setup your JMeter Process to include the Beanshell-server (see the link above) then you can simply replace the code in your post-processor:
${__setProperty("url", "google")};
with the code to connect to the beanshell server and execute that command there instead:
exec("./updateprop.bash url google");
JMeter properties are global therefore once you set the property it is available for all threads
Each JMeter thread (virtual user) executes Samplers. Pre and Post processors are obeying JMeter Scoping Rules Looking into your test plan the execution order is following:
Beanshell PreProcessor
HTTP Request Sampler
Beanshell PostProcessor
therefore HTTP Request sampler will never hit youtube (unless you run into a race condition due to concurrency) because PreProcessor will set the URL back to google
It is recommended to use JSR223 Test Elements and Groovy language for scripting since JMeter 3.1
It is NOT recommended to inline JMeter Functions and/or variables into scripts, you need to either use "Parameters" section or go for code-based equivalents instead so you need to replace this line:
${__setProperty("url", "youtube")};
with this one:
props.put("url", "youtube");
This question is similar to this one I previously asked, in that I want the task to perform a Target Worker Expression check on a list of WorkerSids that I've added as one of the task's attributes. But I think this problem is different enough to warrant its own question.
My goal is to associate a "do not contact" list of WorkerSids with a Task; these are workers who should not be assigned the task (maybe the customer previously had a bad interaction with them).
I have the following workflow configuration:
{
"task_routing":{
"filters":[
{
"filter_friendly_name":"don't call self",
"expression":"1==1",
"targets":[
{
"queue":queueSid,
"expression":"(task.caller!=worker.contact_uri) and (worker.sid not in task.do_not_contact)",
"skip_if": "workers.available == 0"
},
{
"queue":automaticQueueSid
}
]
}
],
"default_filter":{
"queue":queueSid
}
}
}
When I create a task, checking the Twilio Console, I can see that the task has the following attributes:
{"from_country":"US","do_not_contact":["WORKER_SID1_HERE","WORKER_SID_2_HERE"],
... bunch of other attributes...
}
So I know that the task has successfully been assigned the array of WorkerSids as one of its attributes.
There is only one worker who is Idle and whose attributes match the queueSid TaskQueue. That worker's SID is WORKER_SID1_HERE, so the only available worker is ineligible to receive the task reservation. So what should happen is that the first target expression worker.sid not in task.do_not_contact returns false, and the task falls through to the automaticQueueSid TaskQueue.
Instead, the task remains in queueSid unassigned. The following sequence of Taskrouter events are logged:
task-queue.entered
Task TASK_SID entered TaskQueue QUEUESID_QUEUENAME
task.created
Task TASK_SID created
workflow.target-matched
Task TASK_SID matched a workflow target
workflow.entered
Task TASK_SID entered Workflow WORKFLOW_NAME
What do I need to change to get the desired workflow behavior?
Changing the skip_if to
"skip_if": "1==1"
solved the problem.
Per Twilio developer support, the worker.sid not in task.do_not_contact returns true for workers who are unavailable but are also not in do_not_contact, so the target expression still returns a set of workers, and then the "skip_if": "workers.available==0" returns false because technically there is one "available" worker--the one who is ineligible due to the do_not_contact list.
What's needed is for the skip_if to always return true, so when the first target processes the task without assigning it, the skip_if then passes it to the next target, as discussed in Taskrouter Workflow documentation:
"TaskRouter will only skip a routing step in a Workflow if:
No Reservations are immediately created when a Task enters the routing step
The Skip Timeout expression evaluates to true"
I have what seemed like a fairly simple requirement for a process that im beginning to question is even possible.
The image below shows my current process. I am trying to achieve two things:
A user creates an initial user task for adding a note, they should be able to add as many notes as they wish with one user task per note
A new sub-process is spawned for each new note (user task) that the user has created.
The process above presents the following problems:
A sub-process should be spawned for each task, however they seem to overwrite each other
Im not sure if the sub-process requires a unique id for each new sub-process spawned
So it turns out that the solution to this question requires a bit of scripting using groovy.
Below is the updated process model diagram, in it I start a new instance of the Complete Task process using a script task then if the user wishes to add more tasks the exclusive gateway can return the user to the Create task (user task) OR finish the process.
I clear down any values in the fields held within the user task within the script task before I pass the scope back to the user task.
The image below shows my Complete Task process that gets called by the main process using a script
Here I avoid using parallel gateways in preference of creating a new instance of the Create Task (user task) and a new instance of the Complete task process (not subprocess) via means of the script.
To start a new instance of the Complete Task process we have to start the process using the function startProcessInstanceByKeyAndTenantId() under a runtimeService instance for the process, although I could also use startProcessInstanceByIdAndTenantId():
//Import required libraries
import org.activiti.engine.RuntimeService;
import org.activiti.engine.runtime.ProcessInstance;
//instantiate RunTimeService instance
RuntimeService runtimeService = execution.getEngineServices().getRuntimeService();
//get tenant id
String tenantId = execution.getTenantId();
//variables Map
Map<String, Object> variables = runtimeService.getVariablesLocal(execution.getProcessInstanceId());
//start process (processId, variables, tenantId)
ProcessInstance completeTask = runtimeService.startProcessInstanceByKeyAndTenantId("CompleteTask", variables, tenantId);
//Clear variables to create a fresh task
execution.setVariable("title", "");
execution.setVariable("details", "");
Using this approach I avoid creating multiple subprocesses from the parent process and instead create multiple processes that run separate from the parent process. This benefits me as if the parent process completes the others continue to run.
Seems like you are updating only one variable (or a single set of variables) as a result of each task. This will override the previous value. use distinct variables, or append something before each variable to mark it unique for the task/ sub-process completed. see collapsed sub-process
Yes, each sub process gets its own unique execution id, But the main execution ID or process instance ID remains same
I want to get names of thread marked as Hogger in weblogic.
I have tried with
ThreadPoolRuntimeMBean.getHoggingThreadCount()
but this gives only count of hogging threads.
Under Self- Tuning Thread Pool Threads
Weblogic is displaying "Thread Name" ,"Stuck" (True/ false) and "Hogger" (True/ false) , So obviously weblogic developer has written some method to get these values.
I am looking for that weblogic inbuilt method (in WLST) or any other way to get names of hogging threads.
PFA Weblogic Screen Shot for more detail
or check image on this link (http://www.munzandmore.com/wp-content/uploads/2012/04/st9.jpg)
Here is a very basic WLST script to accomplish this (for a default non-clustered AdminServer installation):
connect('weblogic', 'welcome1')
serverRuntime()
cd('ThreadPoolRuntime/ThreadPoolRuntime')
for thread in cmo.getExecuteThreads():
print(thread.getName() + " - " + str(thread.isHogger()))
You can use print dir(thread) to get all the available properties and methods.
For a more complex managed server environment, you can combine the above with this example: http://wlstbyexamples.blogspot.co.za/2009/06/self-tuned-thread-pool-count.html#.ViCqTnVStBc
I am trying to change the name of a thread in QNX 6.4.1, but the threads continue to be listed with the parent process name in a "pidin" listing.
I have created the thread:
iReturn = pthread_create(&threadhandle, &attr, &CALzoneCommThread, this);
I have renamed the thread from within the thread itself:
iReturn = pthread_setname_np(NULL, "HappyThread");
I have read the thread name back:
iReturn = pthread_getname_np(NULL, thread_name, 80);
And all threads return the name "HappyThread" as verified with printf statements, yet when I do a pidin, they are still listed with the process name "testapp". I need some help determining whether I have done something wrong in the code above, or if I am fundamentally misunderstanding the pidin command.
Due to a requirement to play nicely with legacy utilities, the threads must have a name other than the process name.
Platform: QNX 6.4.1
Language: C
Yes, you have done something wrong in the code AND you are misunderstanding the output of the pidin command:
The behavior of your code is unspecified because you are passing NULL (which gets converted to 0) as the thread-id. QNX numbers its threads from 1, therefore thread 0 is unspecified. Experimentation shows that passing 0 for the TID behaves identically to passing 1, for both pthread_setname_np and pthread_getname_np. Therefore, your code is setting and getting the ID of the main thread and not that of the thread you created via the pthread_create() call. You should pass threadhandle as the parameter of the set/get_name calls to actually refer to the newly created thread:
iReturn = pthread_setname_np(threadhandle, "HappyThread");
With no arguments pidin does not display the thread-name set via pthread_setname_np() at all. When called with no arguments pidin displays the process ID in the first column, the thread ID (numeric) in the second column and the name of the process in the third column (that's what you likely misunderstood for the thread-name).
you can call pidin with argument 'threads' as suggested by others above; this will display the thread-name in the third column if one has been set up or the numeric thread ID otherwise. Alternatively, you can call pidin similar to the following in order to get both the numeric and symbolic (if available) ID-s of each thread:
pidin -faNbh
For each thread in the system this will print the PID, process-name, TID and thread-name in that order. Refer to "use pidin" for how that works.