I faced behaviour of EntryProcessor that seemed a bit strange for me.
First of all what I was doing.
My task is to use EntryProcessor to fill cache B from data of another cache A.
Cache A could contain from 100K to 1M entries. So I had no choice but loop through it create B cache key from A data entry and run EntryProcessor on such key to create entry of B cache.
I found when I run such loop and build B cache from A and call EntryProcessor many times (number equals to number of entries in cache A) overall duration changes from time to time.
So I've started to write log in every step of procedure. Sometimes entry processor run with a pause between execution on several entries, see log
16:47:17.773 ce23b7a [thread-7] AppendingProcessor process process; enter
16:47:17.773 7d9a120 [thread-7] AppendingProcessor process process; exit
Pause between two threads (invocation on different keys) is about 10ms (which could give us 100s on 100k keys!)
16:47:17.782 ce23b7a [thread-0] AppendingProcessor process process; enter
16:47:17.782 7d9a120 [thread-0] AppendingProcessor process process; exit
Sometimes we could see another behaviour, without any pause or with very small pause between execution on different entries.
14:38:42.685 ce23b7a [thread-0] AppendingProcessor process - process; enter
14:38:42.685 7d9a120 [thread-0] AppendingProcessor process - process; exit
14:38:42.686 ce23b7a [thread-1] AppendingProcessor process - process; enter
14:38:42.686 7d9a120 [thread-1] AppendingProcessor process - process; exit
14:38:42.686 ce23b7a [thread-6] AppendingProcessor process - process; enter
14:38:42.686 7d9a120 [thread-6] AppendingProcessor process - process; exit
I thought it could be related to partitioning, so it could be related how much partitions I have and whether entryprocessor works with entries from same partition or not, but now I don't think that's the case.
Sometimes when I run the code it works on many entries with no pause, then pause (typically 10ms), then again work with no pause at all
2016-10-25 18:23:34.486 [thread-2] AppendingProcessor - process.exit; partId = 114
....
about 500 entries processed in 1 ms
...
2016-10-25 18:23:34.486 [thread-3] AppendingProcessor - process.exit; partId = 115
....
about 250 entries processed in 1 ms
...
2016-10-25 18:23:34.487 [thread-3] AppendingProcessor - process.exit; partId = 115
My question is what could be the cause of the pause between processing entries in EntryProcessor, especially if pause occurs between each two calls of process method.
Cause such 10 ms pauses don't seem right, what could be the case?
I can't provide real example of code due to NDA but I write an example of the code, see AddressMapBean#process method
and appropriate AddressBookProcessor entry processor.
Any help would be appreciated!
Do you read from A and put into B inside the processor? If so this has a risk of deadlock. See:
https://groups.google.com/forum/#!topic/hazelcast/27_6iS4oaSY
also see:
https://github.com/hazelcast/hazelcast/issues/3146
Another (maybe) possible cause can be thread contention. From documentation:
NOTE: Entry Processors run via Operation Threads that are dedicated to
specific partitions. Therefore, with long running Entry Processor
executions, other partition operations such as map.put(key) cannot be
processed. With this in mind, it is good practice to make your Entry
Processor executions as quick as possible.
Related
Whenever I execute a trace file that I created using a pin tool, I get this on the terminal
Heartbeat CPU 0 instructions: 10000003 cycles: 2500068 heartbeat IPC: 3.99989 cumulative IPC: 3.99989 (Simulation time: 0 hr 0 min 20 sec), followed by reached end of trace and I tried to execute different matrix multiplication trace files with different matrix sizes and it takes the same amount of time to execute all of them (30 mins) does anyone know what's the problem and how to fix it?
I tried executing a trace file provided by 3rd Data Prefetching Championship (DPC-3) and it works just fine and I don't get reached end of trace on the terminal and when I executed different trace files all of them took different amount of time
I have a requirement where I need to execute 4 jobs parallel and when same items job is done in all 4 processors parallely then trigger the next processor for this I have used wait-notify
Flow is like
4 parallel jobs -> notify (release signal identifier = ${itemid}, signal counter name = ${processorname}) -> wait (release signal identifier = ${itemid}, target signal count = 4) and wait relationship is connected to the same wait processor-> next processor
This works for first time but I have noticed that wait queue is not cleared even after the target signal count condition is met and i guess that is the problem it is not working for subsequent flows.
It should clear the waiting queue once the criteria is met right?
I am trying to limit the execution time of a ruby process using the following code:
trap("XCPU") do
abort "Max Time exceeded"
end
Process.setrlimit(:CPU, 5)
loop do
end
The process does end but the trap code does not run (I just get 'killed' on the command line). However when I set the hard limit to a value greater than 5 the trap code runs
trap("XCPU") do
abort "Max Time exceeded"
end
Process.setrlimit(:CPU, 5, 6)
loop do
end
Why is the first code not working?
The XCPU signal (SIGXCPU) is only sent upon a soft limit. When the hard limit is reached, a KILL signal (SIGKILL) is sent instead. KILL signals cause the program to terminate immediately, and cannot be caught.
Taken from here:
The XCPU signal is sent to a process when it has used up the CPU for a
duration that exceeds a certain predetermined user-settable value. The
arrival of an XCPU signal provides the receiving process a chance to
quickly save any intermediate results and to exit gracefully, before
it is terminated by the operating system using the SIGKILL signal.
The KILL signal is sent to a process to cause it to terminate
immediately. In contrast to SIGTERM and SIGINT, this signal cannot be
caught or ignored, and the receiving process cannot perform any
clean-up upon receiving this signal.
By calling Process.setrlimit without a second parameter, the hard limit defaults to being equal to the soft limit. As such, at least on your operating system, it seems the SIGKILL is being sent before a SIGXCPU can be handled by your trap block.
Here is a quick demo to show why the second approach always works:
t = Time.now
trap("XCPU") do
abort "Max Time exceeded. Total running time: #{(Time.now - t).round} seconds"
end
Process.setrlimit(:CPU, 2, 5)
loop do
end
# => "Max Time exceeded. Total running time: 2 seconds"
The hard limit is not reached before the trap block executes, so the code runs as you expect.
I have to create a delay of say 20 ms in a process waiting in an input button.
I wrote the following code and it gives an error
wait until clk'EVENT and clk='1';
wait for 20 ms;
Or, can I use a construct like:
wait for 20 ms until clk'EVENT and clk='1';
Any help is highly appreciated.
You can wait for an event, for time, or for both (or neither--but that is a unique case).
Now, I'm not quite sure why your first example gives an error since it is a valid sequential statement. But you have not provided a complete example nor the error code. So, my answer here will be pretty basic.
First, a wait statement can only occur as a sequential statement, essentially meaning only in a process (or called from a process). So, if you are trying to use it concurrently, it is a problem.
Now, if you are using it from a process, it must be in a process without a sensitivity list. That is, the following is illegal:
process(clk)
begin
wait until clk'EVENT and clk='1';
end process;
It must be a bare process, such as:
process
begin
wait until clk'EVENT and clk='1';
end process;
A bit more on your first example (properly placed in a sequential context and does compile):
process
begin
wait until clk'EVENT and clk='1';
wait for 20 ms;
end process;
This code waits for a rising edge on clk, and then waits for 20ms. These are sequentially executed (hence the sequential context in a process).
Your second statement needs to be tweaked to compile. Generally, a wait statement has the form wait until <event> for <time>, where both event and time are optional. For example:
process
begin
wait; -- No event, no time. Wait forever.
wait until clk'event and clk='1'; -- Wait forever for a rising edge on 'clk'
wait for 20 ms; -- Wait for 20 ms
wait until clk'event and clk='1' for 20 ms; --Wait for up to 20 ms for a rising edge on 'clk'
end process;
So, your second example has the order backward for event and time.
Finally, your introductory text indicates you are waiting for 20ms for a push button. This hints that you are trying to create real logic. The wait statement is synthesizable only in very limited use cases. And one of the cases specifically excluded is waiting for a period of time. If you need to wait for 20 ms, you'll need to do it some other way (such as counting clocks). And if you are trying to wait up to 20 ms for the button, it'll have to be a combination of detecting the change on the pushbutton and counting clocks.
My requirement is like this:
1. Run one full round of test using jmeter
2. Wait for 90 secs
3. Restart step1
4. I have to continue step1 and this entire process continues for 4 days.
Can someone help me how to add the delay after all the threads have been executed
Create a thread group with 1 thread with a loop count of forever and and click "scheduler". Set a start time and end time.
Put your tests within the thread.
Add a constant timer after the last test (still within the thread group though) and within thread delay, use 90000. (This converts to 90 seconds)