Thanks Scott. I didn't even realize there was a non-GUI mode, but I see it now in the
documentation (since I am looking for it, I guess).
I am able to duplicate it in non-gui mode, but not in gui mode. I will do some
further looking into it.
Thanks,
Jonathan
>>> [EMAIL PROTECTED] 12/22/02 05:08AM >>>
Jonathan,
Your fix may function well under some circumstances, but is does not seem to
cater for non-gui testing where I end up with a jmeter.log full of these (I
don't think I checked the log when I was running in gui mode):
12/22/2002 9:08:27 PM ERROR - jmeter.engine: java.lang.ClassCastException
at
org.apache.jmeter.assertions.ResponseAssertion.getTestPatterns(ResponseAsser
tion.java:166)
at
org.apache.jmeter.assertions.ResponseAssertion.evaluateResponse(ResponseAsse
rtion.java:368)
at
org.apache.jmeter.assertions.ResponseAssertion.getResult(ResponseAssertion.j
ava:268)
at
org.apache.jmeter.threads.JMeterThread.checkAssertions(JMeterThread.java:179
)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:144)
at java.lang.Thread.run(Thread.java:536)
Can you please verify this Jonathan - I guess there is a possibility that I
miss-typed your code.
I added a couple of debug statements immediately prior to the error, these
produce:
getProperty(TEST_PATTERNS) =
org.apache.jmeter.assertions.ResponseAssertion$3@4445b5
getProperty(TEST_PATTERNS).getClass().getName() = java.lang.String
Which doesn't seem quite right to me.
I'll mark the patch as not to be applied until we sort this out.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
.Mac Chat/AIM: seade at mac dot com
On 21/12/2002 1:35 AM, "Jonathan Carlson" <[EMAIL PROTECTED]> wrote:
> Thanks again, Scott, for preparing the patch.
>
> To answer your question on how pinned down the problem was, I was able to
> reproduce it on a run of a dozen or so requests that had 10 threads running.
> Which request and which thread that it occurred on was variable for each run,
> although it did happen on some requests more than others. I'm not sure why.
>
> Jonathan
>
>
>
>>>> [EMAIL PROTECTED] 12/20/02 07:06AM >>>
> Hi Michal,
>
> Short answer: No.
>
> Longer answer:
> a. in my experience issues relating to thread safety can sometimes be a
> little tricky to reproduce, let alone to reproduce consistently (I do note
> your use of 'almost unfailing'). I get the impression that Jonathan may in
> face have such an example, but whether or not he can provide it and whether
> or not it can be formulated into a test case is another story.
> b. either it is thread safe or it isn't - if it isn't then the fix is
> required (the added performance and javadoc are also beneficial). I am
> trusting Jonathan's statement that the matcher and compiler are not thread
> safe.
>
> All in all I am seeking to ensure that my test cases work correctly. To
> this end I had implemented Jonathan's patch locally. I simply volunteered
> to provide the patch for commit because Jonathan lacked the facilities to do
> so himself.
>
> Can you please clarify the motivation for your query? Are you promoting a
> "no patches without test cases" philosophy or is there something special
> about this particular change that concerns you?
>
> Cheers,
>
> Scott
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
**********************************************************************
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
