You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by João Tiago Ferreira <jo...@novabase.pt> on 2010/06/18 20:27:14 UTC
Re: JMS Assertion??
Hi
I was interested in such a feature. It was implemented?
Best regards
João Ferreira
On Monday 16 February 2009 17:02:32 sebb wrote:
> On 16/02/2009, Noel O'Brien <no...@newbay.com> wrote:
> > On Monday 16 February 2009 16:35:56 sebb wrote:
> > > On 16/02/2009, Noel O'Brien <no...@newbay.com> wrote:
> > > > On Monday 16 February 2009 15:42:46 sebb wrote:
> > > > > On 16/02/2009, Noel O'Brien <no...@newbay.com> wrote:
> > > > > > Hi All,
> > > > > >
> > > > > > The web application I'm testing uses JMS queues for
> > > > > > communicating externally when certain events occur. The JMS
> > > > > > point to point sampler in JMeter only provides for Request and
> > > > > > Request/Response tests, however almost all of the messaging I
> > > > > > will be testing will be driven by a HTTP request, i.e. make a
> > > > > > HTTP request and there should be a corresponding message on a
> > > > > > JMS queue.
> > > > > >
> > > > > > What is the best way to (at least) functionally test this? I
> > > > > > was thinking of writing a JMS Assertion that I could add to the
> > > > > > HTTP Request sampler, does that sound reasonable? The JMS
> > > > > > message occurs as a result of the HTTP request being made so to
> > > > > > me it makes sense for it to be an assertion.
> > > > >
> > > > > Is the JMS message sent before the HTTP response is returned? Can
> > > > > one guarantee this?
> > > > > I thought JMS was asynchronous.
> > > >
> > > > JMS is indeed asynchronous. The HTTP response will always return
> > > > first, and the logic that puts the message on the queue is run in a
> > > > background thread which has a default pause interval or 30 seconds.
> > > > So there would be a maximum 30 second delay between the http request
> > > > completing and the message appearing on the queue
> > > >
> > > > > I would expect the HTTP Response Assertion to be used for
> > > > > checking that the HTTP response is OK, i.e. the page contains
> > > > > "message sent OK" or whatever.
> > > > >
> > > > > > Is there any other way of having a "Response" only JMS
> > > > > > sampler?
> > > > >
> > > > > I've never used JMS, but isn't that what JMS Subscriber does?
> > > >
> > > > We are not using topic/subscriber model for JMS, but queues (FIFO).
> > > > Will the JMS Subscriber sampler work with queues?
> > >
> > > No idea, sorry.
> > >
> > > > > i.e what does the intended JMS recipient do?
> > > >
> > > > The intended JMS recipient parses the message and does further
> > > > processing. In our example, it's an SMS gateway, but is outside the
> > > > scope of our app, so I do not need to test it. I do need to test
> > > > that the correct messages are coming off the queue (in quantity and
> > > > content) and will need to performance test it in future
> > >
> > > I meant - what JMS actions does the recipient do to acquire the
> > > message, not what it does with the message once received.
> >
> > I have no idea how the SMS gateway interacts with the queue, but as it's
> > written in Java I assume it would use the onMessage() function.
>
> Presumably it will have to do something first in order to use that
> function.
>
> > I will investigate further the JMS Subscriber sampler and report my
> > findings.
>
> Thanks.
>
> If it turns out that there is a missing aspect of JMS that JMeter
> could implement, then we can see about adding it for a future release.
I tried using a JMS Subscriber sampler to take some messages off a queue, but
the following exception happened in jmeter.log:
2009/02/16 17:04:20 ERROR - jmeter.threads.JMeterThread:
java.lang.ClassCastException: com.swiftmq.jms.QueueImpl cannot be cast to
javax.jms.Topic
at
org.apache.jmeter.protocol.jms.client.InitialContextFactory.lookupTopic(InitialContextFactory.java:80)
at
org.apache.jmeter.protocol.jms.client.OnMessageSubscriber.initConnection(OnMessageSubscriber.java:119)
at
org.apache.jmeter.protocol.jms.client.OnMessageSubscriber.<init>(OnMessageSubscriber.java:79)
at
org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.initListenerClient(SubscriberSampler.java:105)
at
org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.sampleWithListener(SubscriberSampler.java:162)
at
org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.sample(SubscriberSampler.java:150)
at
org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.sample(SubscriberSampler.java:137)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:290)
at java.lang.Thread.run(Thread.java:619)
It looks like the sampler is trying to get a reference to a topic but the
instance hosted by SwiftMQ is a queue, so no dice.
> If none of the existing JMS samplers do what you want, then some code
> will have to be written in order to solve your problem - whether as an
> Assertion or a Sampler.
I'm going to extend the existing JMS sampler to work in Response mode. I'm
interested in contributing back to the project too :)
I've already modified it to work with MapMessage as opposed to just
TextMessage types.
> The BeanShell elements may be useful for prototyping.
Thanks for the tip :)
Noel
> > Thanks for your help,
> >
> > Noel
> >
> > > > Regards,
> > > >
> > > > Noel
> > > >
> > > > > > Regards,
> > > > > > Noel
> > > > > >
> > > > > >
> > > > > > ---------------------------------------------------------------
> > > > > >----- - 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
> > >
> > > ---------------------------------------------------------------------
> > > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: JMS Assertion??
Posted by sebb <se...@gmail.com>.
No.
Patches welcome!
(via Bugzilla please)
On 18/06/2010, João Tiago Ferreira <jo...@novabase.pt> wrote:
> Hi
>
> I was interested in such a feature. It was implemented?
>
> Best regards
>
> João Ferreira
>
>
> On Monday 16 February 2009 17:02:32 sebb wrote:
> > On 16/02/2009, Noel O'Brien <no...@newbay.com> wrote:
> > > On Monday 16 February 2009 16:35:56 sebb wrote:
> > > > On 16/02/2009, Noel O'Brien <no...@newbay.com> wrote:
> > > > > On Monday 16 February 2009 15:42:46 sebb wrote:
> > > > > > On 16/02/2009, Noel O'Brien <no...@newbay.com> wrote:
> > > > > > > Hi All,
> > > > > > >
> > > > > > > The web application I'm testing uses JMS queues for
> > > > > > > communicating externally when certain events occur. The JMS
> > > > > > > point to point sampler in JMeter only provides for Request and
> > > > > > > Request/Response tests, however almost all of the messaging I
> > > > > > > will be testing will be driven by a HTTP request, i.e. make a
> > > > > > > HTTP request and there should be a corresponding message on a
> > > > > > > JMS queue.
> > > > > > >
> > > > > > > What is the best way to (at least) functionally test this? I
> > > > > > > was thinking of writing a JMS Assertion that I could add to the
> > > > > > > HTTP Request sampler, does that sound reasonable? The JMS
> > > > > > > message occurs as a result of the HTTP request being made so to
> > > > > > > me it makes sense for it to be an assertion.
> > > > > >
> > > > > > Is the JMS message sent before the HTTP response is returned? Can
> > > > > > one guarantee this?
> > > > > > I thought JMS was asynchronous.
> > > > >
> > > > > JMS is indeed asynchronous. The HTTP response will always return
> > > > > first, and the logic that puts the message on the queue is run in a
> > > > > background thread which has a default pause interval or 30 seconds.
> > > > > So there would be a maximum 30 second delay between the http request
> > > > > completing and the message appearing on the queue
> > > > >
> > > > > > I would expect the HTTP Response Assertion to be used for
> > > > > > checking that the HTTP response is OK, i.e. the page contains
> > > > > > "message sent OK" or whatever.
> > > > > >
> > > > > > > Is there any other way of having a "Response" only JMS
> > > > > > > sampler?
> > > > > >
> > > > > > I've never used JMS, but isn't that what JMS Subscriber does?
> > > > >
> > > > > We are not using topic/subscriber model for JMS, but queues (FIFO).
> > > > > Will the JMS Subscriber sampler work with queues?
> > > >
> > > > No idea, sorry.
> > > >
> > > > > > i.e what does the intended JMS recipient do?
> > > > >
> > > > > The intended JMS recipient parses the message and does further
> > > > > processing. In our example, it's an SMS gateway, but is outside the
> > > > > scope of our app, so I do not need to test it. I do need to test
> > > > > that the correct messages are coming off the queue (in quantity and
> > > > > content) and will need to performance test it in future
> > > >
> > > > I meant - what JMS actions does the recipient do to acquire the
> > > > message, not what it does with the message once received.
> > >
> > > I have no idea how the SMS gateway interacts with the queue, but as it's
> > > written in Java I assume it would use the onMessage() function.
> >
> > Presumably it will have to do something first in order to use that
> > function.
> >
> > > I will investigate further the JMS Subscriber sampler and report my
> > > findings.
> >
> > Thanks.
> >
> > If it turns out that there is a missing aspect of JMS that JMeter
> > could implement, then we can see about adding it for a future release.
>
> I tried using a JMS Subscriber sampler to take some messages off a queue, but
> the following exception happened in jmeter.log:
>
> 2009/02/16 17:04:20 ERROR - jmeter.threads.JMeterThread:
> java.lang.ClassCastException: com.swiftmq.jms.QueueImpl cannot be cast to
> javax.jms.Topic
> at
> org.apache.jmeter.protocol.jms.client.InitialContextFactory.lookupTopic(InitialContextFactory.java:80)
> at
> org.apache.jmeter.protocol.jms.client.OnMessageSubscriber.initConnection(OnMessageSubscriber.java:119)
> at
> org.apache.jmeter.protocol.jms.client.OnMessageSubscriber.<init>(OnMessageSubscriber.java:79)
> at
> org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.initListenerClient(SubscriberSampler.java:105)
> at
> org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.sampleWithListener(SubscriberSampler.java:162)
> at
> org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.sample(SubscriberSampler.java:150)
> at
> org.apache.jmeter.protocol.jms.sampler.SubscriberSampler.sample(SubscriberSampler.java:137)
> at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:290)
> at java.lang.Thread.run(Thread.java:619)
>
> It looks like the sampler is trying to get a reference to a topic but the
> instance hosted by SwiftMQ is a queue, so no dice.
>
> > If none of the existing JMS samplers do what you want, then some code
> > will have to be written in order to solve your problem - whether as an
> > Assertion or a Sampler.
>
> I'm going to extend the existing JMS sampler to work in Response mode. I'm
> interested in contributing back to the project too :)
>
> I've already modified it to work with MapMessage as opposed to just
> TextMessage types.
>
> > The BeanShell elements may be useful for prototyping.
>
> Thanks for the tip :)
>
> Noel
>
> > > Thanks for your help,
> > >
> > > Noel
> > >
> > > > > Regards,
> > > > >
> > > > > Noel
> > > > >
> > > > > > > Regards,
> > > > > > > Noel
> > > > > > >
> > > > > > >
> > > > > > > ---------------------------------------------------------------
> > > > > > >----- - 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
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
>
>
>
>
>
> ---------------------------------------------------------------------
> 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