On 15/04/2008, Krzysieq <[EMAIL PROTECTED]> wrote: > In the end, I think it turns out to be a bug in our project's code - albeit > a very subtle one. We moved down to an earlier version, and the tests were > successful again. It is very strange that this also happens to old code on > another machine, however... How's the response saved to file different from > the one shown on gui? Cause when we inspected those, there was nothing wrong > with them - well formatted, proper xml responses.
No difference. But the Save Response element can be used from non-GUI (batch) runs, and it is cheaper than View Results Tree, since it does not keep a copy of the data. > Thanks for help. Cheers, > Chris > > 2008/4/14, sebb <[EMAIL PROTECTED]>: > > > > > On 14/04/2008, Krzysieq <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > I started experiencing this strange problem this morning. We have a > > bunch of > > > tests for a webservice, that are executed via CruiseControl every > > night, or > > > more often if there's a need. Since the webservice is supposed to > > return > > > xml, those tests contain xml assertions, but without any schema or dtd, > > or > > > any such thing. I assume this means, that the response is only > > validated on > > > the account of being properly formatted xml. > > > > > > Up to this morning everything > > > was running smoothly, but suddenly over this weekend we started to have > > some > > > strange errors returned by the tests. > > > > > > The xml asertion returns this message > > > > > > > > > Error on line 1: The processing instruction target matching > > "[xX][mM][lL]" > > > is not allowed. > > > This error has never happened to us before. The funny thing is that is > > > suddenly started to happen simultaneously on two different platforms, > > one of > > > which holds always the latest code, while the other is "frozen" at some > > > stage of development for integration testing. A this moment the code on > > that > > > platform is 2 weeks old. We get less errors like this from it, but they > > > still appear. The other important detail is that when I execute the > > tests in > > > gui mode, the assertion still fails on the latest code, but on the 2 > > weeks > > > old it doesn't. Thing is responses are correct in both cases - they are > > well > > > formatted xml, and they can even be rendered correctly by the jmeter's > > gui. > > > > > > Has anyone ever seen anything similar, or has any idea as to why this > > might > > > be happening? Any ideas will be welcome. The automatic tests use jmeter > > > 2.3RC3, while my local uses machine has 2.3.1. > > > > > > > > > No idea what could cause this, except perhaps a subtle threading bug. > > However the XML Assertion uses a different parser for each thread. > > > > I suggest you add a Save Response to File Post-Processor - with Save > > failed responses only checked - so you can see exactly what data was > > returned, in case there is a problem with the data. > > > > > Regards, > > > Chris > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
