I am using parallel processing.
CALL FUNCTION 'ZABC' STARTING NEW TASK taskname
DESTINATION IN GROUP srv_grp PERFORMING come_back ON END OF TASK
EXPORTING
...
EXCEPTIONS
...
.
I am calling this FM inside a loop. sometimes, my records are skipped. I am not getting a desired output. Sometimes 2000 records are processed and sometimes 1000. The numbers are varying. what can be the problem ? Can you provide me some cases where records can be skipped in parallel processing ?
See the example code SAP provides: https://help.sap.com/viewer/753088fc00704d0a80e7fbd6803c8adb/7.4.16/en-US/4892082ffeb35ed2e10000000a42189d.html
Look at how they handle the resource exceptions. A resource exception means that you tried to start a new aRFC but there were no more processes available. Your program has to handle these cases. Without handling these cases the entries will be skipped. The normal handling is to just wait a little time for some of the active processes to finish, in the example program:
WAIT UNTIL rcv_jobs >= snd_jobs
UP TO 5 SECONDS.
gv_semaphore = 0.
" your internal table size.
DESCRIBE TABLE lt_itab LINES lv_lines.
LOOP AT lt_itab INTO ls_itab.
" parallel proc. -->>
CALL FUNCTION 'ZABC' STARTING NEW TASK taskname
DESTINATION IN GROUP srv_grp PERFORMING come_back ON END OF TASK
EXPORTING
...
EXCEPTIONS
...
.
" <<--
ENDLOOP.
" wait until all parallel processes have terminated. **
WAIT UNTIL gv_semaphore = lv_lines.
NOTE: You should check total parallel process count. There should be some upper limits for opened threads.
Thanks.
Related
I have this test
defmodule InfoSys.Backends.WolframTest do
use ExUnit.Case, async: true
alias InfoSys.WolFram
test "make request, report results, then terminates" do
ref = make_ref()
{:ok, pid} = WolFram.start_link("1 + 1", ref, self(), 1)
assert_receive {:results, ^ref, [%InfoSys.Result{text: "2"}]}
end
end
and I am receiving
No message matching {:results, ^ref, [%InfoSys.Result{text: "2"}]}
after 100ms.
How can I know which message is ref receiving or how can I debug this error? I am following phoenix book programming example
Whole ExUnit stacktrace:
1) test make request, report results, then terminates (InfoSys.Backends.WolframTest)
test/backends/wolfram_test.exs:6
No message matching {:results, ^ref, [%InfoSys.Result{text: "2"}]} after 100ms.
The following variables were pinned:
ref = #Reference<0.214527998.4009754625.219099>
The process mailbox is empty.
code: assert_receive {:results, ^ref, [%InfoSys.Result{text: "2"}]}
stacktrace:
test/backends/wolfram_test.exs:11: (test)
I've ran on these kind of problems before. There are two probable causes:
Your process is taking longer than 100 ms to give you the result.
Your process has a bug.
I prefer to rule out the first possibility and the thing I do is making the test wait more than the default time which is 100 ms. assert_receive can receive a second argument which is the time in milliseconds. You can try something like this:
assert_receive {:results, ^ref, [%InfoSys.Result{text: "2"}]}, 5000
where 5000 means 5000 ms or 5 seconds.
After increasing the time, there are two possible outcomes when running a test like this:
Your test mailbox is not empty: your process is slow when processing your requests. Nothing wrong with the logic. Maybe the thing your process is doing is an expensive operation or you need to improve your code's efficiency.
Your test mailbox is empty:
There is definitely a problem with the logic of your process and you
should check the code.
You have underestimated the complexity of the operation your process should do and you should find a more efficient way of doing it or change your solution.
I've seen the code you are taking about and it's not too complex (next time you should post it as part of the question), so if you don't receive a response in your test after 5 seconds, then there is definitely something wrong with your process' code.
I hope this helps.
This might be a silly mistake from my side that I have overlooked but I'm fairly new to UVM and I tried tinkering with my code for a while before this. I'm trying to send in a stream of 8 bit data within a packet using Data valid stall protocol from my UVM driver to the DUT. I'm facing an issue with my input monitor not being able to pick up these transactions that are driven.
I have a while loop with a condition that the valid bit must be high and the stall bit should be low. As long as this condition holds good, the monitor needs to pick up the data byte and push into the queue. I know for a fact that the data is being picked up and pushed to a queue as I used $display statements along the way. The problem is arising once all the data bytes are received and the valid bit goes low. Ideally, this should cause the exit from the while loop but isn't doing so. Any help here would be appreciated. I have attached a snippet of the code below. Thanks in advance.
virtual task main_phase (uvm_phase phase);
$display("Run phase of input monitor");
collect_transfer();
endtask: main_phase
virtual task collect_transfer();
fork
forever begin
wait_for_valid_transaction_cycle();
create_and_populate_pkt();
broadcast_pkt();
#(iP0_vif.cb_iP0_MON);
end
join_none
endtask: collect_transfer
virtual task wait_for_valid_transaction_cycle();
wait(iP0_vif.cb_iP0_MON.ip_valid && ~iP0_vif.cb_iP0_MON.ip_stall);
endtask: wait_for_valid_transaction_cycle
virtual task create_and_populate_pkt();
pkt = Router_seq_item :: type_id :: create("pkt");
pkt.valid = iP0_vif.cb_iP0_MON.ip_valid;
pkt.sop = iP0_vif.cb_iP0_MON.ip_sop;
$display("before data collection");
while(iP0_vif.cb_iP0_MON.ip_valid === `HIGH && iP0_vif.cb_iP0_MON.ip_stall === `LOW) begin
$display("After checking for stall");
pkt.data = iP0_vif.cb_iP0_MON.ip_data;
$display(pkt.data);
pkt.data_q.push_front(pkt.data);
pkt.eop = iP0_vif.cb_iP0_MON.ip_eop;
$display("print check in input monitor # time = %0t", $time);
#(iP0_vif.cb_iP0_MON);
end
$display("before printing input packet from monitor");
Check_for_port_route_and_populate_packet_field(pkt);
print_packet(pkt);
endtask: create_and_populate_pkt
The $display statement "before printing input packet from monitor" is not being displayed.
HIGH is defined as a binary 1 and LOW is defined as a binary 0.
The output of the code in terms of display statements is as below.
before data collection
before checking for stall
After checking for stall
2
print check in input monitor # time = 105
before checking for stall
After checking for stall
1
print check in input monitor # time = 115
before checking for stall
After checking for stall
3
print check in input monitor # time = 125
It's possible that the main phase objection is being dropped elsewhere in your environment. UVM will automatically kill any threads that were spawned during a phase when it ends.
To fix this, do not object to the main phase in your monitor. Objecting to that phase is the responsibility of the threads creating the stimulus. Instead, you should be launching this monitor during the run_phase, which will ensure that your loop is not killed until the end of simulation.
Also, during the shutdown phase, you will want your monitor to object whenever it is currently seeing a packet. This will ensure that simulation doesn't end as soon as stimulus has been sent in, giving your other monitors time to collect responses from the DUT.
I ran into an issue where I had long running JitterBit operations that were scheduled. I had them scheduled close together, since I needed to keep data flowing. But, when they would take longer than expected I would wind up with multiple instances of the operation set running at the same time. This was killing my performance.
I'll put the fix in the answer below.
To resolve this issue I added an additional Script Operation at the beginning of my operation set (with the schedule running on this operation). This script simply checks to see if one of the operations in this set is already running. If not, it starts the next operation. If there is anything running, it exists and waits till the next scheduled instance.
This is a sample of my script. This one assumes that there were originally two operations in this operation set.
<trans>
$isInQueue=GetOperationQueue("<TAG>Operations/OperationToCheck01</TAG>");
$isInQueue2=GetOperationQueue("<TAG>Operations/OperationToCheck02</TAG>");
$isRunning=$isInQueue[0][1];
$isRunning2=$isInQueue2[0][1];
if(($isRunning==1 && $isRunning!=Null()) || ($isRunning2==1 && $isRunning2!=Null()),
WriteToOperationLog("Skip for now: "+$isRunning+" / "+$isRunning2);,
WriteToOperationLog("Nothign is Running - Starting Operation Chain.");
RunOperation("<TAG>Operations/OperationToCheck01</TAG>");
);
</trans>
I want to post some bulk messages. System takes some time to process them, so i do not want to proceed for 2nd iteration. My setup is something like this
While controller->jdbc request->beanshell postprocessor
In While controller, condition is ${__java script("${check_1}" != "0")}
check is the variable name as part of database sampler which checks whether all the messages are processed. Its a count, if it is 0 we have to stop looping.
As part of Bean Shell Post Processor, i have added a condition to wait if count is not equal to 0.
if(${check_1} != 0) {
out("check Count not zero, waiting for 5 sec " + ${check_1});
Thread.sleep(5000);
}else
out("check Count is zero " + ${check_1});
Whats happening is, the result is something like this
If the check_1 is > 0 , it waits for 5 sec and as soon as it is 0, it runs into infinite loop by executing the sampler multiple times
Is there something wrong with the condition. Please suggest if you have any other solution.
The correct way to use __javaScript() function and define condition is:
${__javaScript(${check_1} != 0,)}
The correct way of accessing JMeter Variables from Beanshell is:
if(vars.get("check_1").equals("0"))
Hope this helps.
I am trying to build a Jmeter test plan that can make http calls to a server. Each thread in the thread group will read 2 parameters from a CSV file and make the http call with the params, and continue to make the same call with same parameters for lets say 1000 times with a delay of 10s between each thread execution.
The http call looks like
/service/method?param1=${param1}¶m2=${param2}
The CSV is like this:
1,2
3,4
5,6
7,8
I have the test plan set up that works for the most part except the single issue. I want each thread to use the same parameters (same line of input) whenever the thread executes. Currently the only way to do it is to set Recycle on EOF = true, but the threads randomly pick the values. Param1 and Param2 can be randomly generated values as long as they stick with the same thread throughout the execution.
Is there anyway I can achieve this?
Thanks!
I'm not really sure I understand your issue right (you can possibly describe it more explicitly or using an example) but the schema below should implement your test-plan description:
Test Plan
Thread Group
Number of Threads: N
. . .
While Controller
Condition: ${__javaScript("${param2"!="<EOF>",)} - read csv-file until the EOF
CSV Data Set Config
Filename: [path to your file with test-data]
Variable Names: param1,param2
Recycle on EOF? False
Stop thread on EOF? True
Sharing mode: Current thread group
Loop Controller
Loop Count = 1000 - number of loops for each thread, with the same params
HTTP Request - your http call
Test Action
Target = Current Thread
Action = Pause
Duration (ms) = 10000 - pause between calls
. . .
In case if you need that each of N threads reads and uses single and unique line from csv-file you have to set Sharing mode: Current thread group for CSV Data Set Config (number of csv-entries should be in this case the sane as threads number, or Recycle on EOF? False should be set otherwise).
In case if you need that each of N threads reads and uses all lines from csv-file you have to set Sharing mode: Current thread for CSV Data Set Config.
If that's not what you want please describe your issue a bit more clear.
I was able to find sort of a hack. Basically I just put a constant timer for each thread and used the thread number ${__threadNum} as the parameter to fit my constraint of having the same parameter to be used by the same thread.
I would still prefer a way to read the params from a csv file.