sebb wrote:
On 02/07/2008, Ronan Klyne <[EMAIL PROTECTED]> wrote:
Ronan Klyne wrote:
sebb wrote:
On 02/07/2008, Ronan Klyne <[EMAIL PROTECTED]> wrote:
Ivan Rodriguez wrote:
You could try to disable one element at the time and run the script.
When the Exception disappear then you will know witch element is
causing
it.
You can of course do it the other way around, disable all and enable
one
element at the time.
The problem with this method is that I have a large test plan
(hundreds of
elements), and it takes about 60 seconds per element.
I'd rather JMeter would just tell me which element wasn't right...
The problem is that the NPE is caused by a bug - it's not expected to
happen, so the method that fails does not do anything about it. The
NPE is eventually caught by the top-level code, but by then the
details of what the low level method was doing are lost.
I take it you are not using any Beanshell script right?
I am using BeanShell, but I'm fairly sure this error is not related
to that
- BeanShell errors have always mentioned 'BeanShell' somewhere in the
message...
Agreed. The offending code is:
SamplePackage pack = (SamplePackage)
samplerConfigMap.get(sampler);
pack.setSampler(sampler); // NPE occurs here
For some reason, the pack cannot be found in the map.
It looks like this might perhaps be a thread synchronisation issue, in
which case the contents of the test plan may not be relevant.
But if the test plan is relevant:
How about checking which test elements are missing from the loaded test
plan?
If it's not obvious visually, try saving the partial test plan and
comparing against the original.
There's no difference. The newly saved plan, if reloaded, exhibits the
same problem.
I have found (by disabling large chunks of test (using XSL - much faster
:D)) that one particular BeanShell preprocessor is causing the problem - at
least, disabling it makes the problem go away.
This is inside a pair of transaction controllers, the outer of which is
set to generate a parent sample. This is all then wrapped is a simple
controller.
Elsewhere, I have a loop which uses a module controller to pull in this
simple controller.
It's not a simple set up, but I'm now looking at where in my BeanShell the
problem might be. I'll keep you posted...
That was a red herring. The problem is with nested transaction controllers
where more than one of them is set to generate a parent sample.
(I got mislead because this code path was being controlled by my Beanshell)
AFAICS, the parent sample option was not present in 2.3RC4, so this
presumably explains why the test plan worked previously.
I'm fairly sure I've seen that option since at least 2.3RC3...
I'm also fairly sure that it never liked nesting such elements, but this
situation only used to result in some duplicate samples - one of the
parent samples was generated in _addition_ to the child samples, rather
than only generating the parent sample.
It also seems to make sense that the TestCompiler might have problems
finding the sample.
Obviously this is a bug which needs fixing, so thanks for reporting it.
It's the least I can do....
--
Ronan Klyne
Business Collaborator Developer
Tel: +44 01189 028518
[EMAIL PROTECTED]
www.groupbc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
