https://bz.apache.org/bugzilla/show_bug.cgi?id=57848
Bug ID: 57848
Summary: JMeter test reliably hangs in non-GUI mode
Product: JMeter
Version: 2.10
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Main
Assignee: [email protected]
Reporter: [email protected]
Created attachment 32679
--> https://bz.apache.org/bugzilla/attachment.cgi?id=32679&action=edit
Further details and strace output
A JMeter load test run on a 1-CPU VM reliably hangs in non-GUI mode. It
always completes in GUI mode. The non-GUI hanging resolved when CPU resources
were added to the VM. However, seemingly random network errors occur in all
scenarios.
The test was run on Linux running in a VirtualBox VM (Fedora 21 guest, Windows
7 host). The VM had 1 CPU (i5 class) and 4 GB RAM allocated initially. Run in
non-GUI mode, the test always 'hung' a long time (in one case, overnight). GUI
mode worked fine, with intermittent errors (the green light would blink out
once the test ended).
The test uses XML/RPC samplers and HTTP samplers. Run in GUI mode, a small
minority of the XML/RPC sampler threads (about 10 out of a total of 100
threads) throw a java.net.UnknownHostException. I think similar exceptions
occur in non-GUI mode, and somehow trigger the hang.
Strace of the hanging Java PID (non-GUI mode test run) revealed a
FUTEX_WAIT/FUTEX_WAKE loop (details below). It reported also "Process 8061
attached with 13 threads" -- these 13 threads seem to correspond to PIDs
(reported at the end of strace output as "Process 8086 detached", "Process
8107 detached", etc). The interesting thing is these 13 PIDs did not exist when
I ran the strace (as reported by 'ps').
Sorry, a thread dump was not obtained. Poking around enough with strace seemed
to cause the JVM to somehow 'recover' and terminate the test (with an
incomplete log file).
First, I increased RAM allocated to the VM in VirtualBox settings. This had no
effect. Then, I tried allocating 2 more CPUs to the VM. This also enabled I/O
APIC in VirtualBox (it was disabled by default earlier).
Adding CPUs resolved the 'hang' problem; the test now completes reliably in
non-GUI mode. But intermittent network problems persist. For e.g., in one run,
one (out of 100) XML/RPC samplers returned a single 'Non HTTP response message:
Network is unreachable' error. The next run passed with no errors.
For further details and strace output, see 'Detailed Information.txt' attached.
--
You are receiving this mail because:
You are the assignee for the bug.
