You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Krzysieq <kr...@gazeta.pl> on 2008/04/14 11:05:52 UTC
Strange behavior of XML assertion
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.
Regards,
Chris
Re: Strange behavior of XML assertion
Posted by sebb <se...@gmail.com>.
On 15/04/2008, Krzysieq <kr...@gazeta.pl> 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 <se...@gmail.com>:
>
> >
> > On 14/04/2008, Krzysieq <kr...@gazeta.pl> 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: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: Strange behavior of XML assertion
Posted by Krzysieq <kr...@gazeta.pl>.
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.
Thanks for help. Cheers,
Chris
2008/4/14, sebb <se...@gmail.com>:
>
> On 14/04/2008, Krzysieq <kr...@gazeta.pl> 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: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: Strange behavior of XML assertion
Posted by sebb <se...@gmail.com>.
On 14/04/2008, Krzysieq <kr...@gazeta.pl> 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: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org