On 16/02/2009, Noel O'Brien <[email protected]> wrote: > On Monday 16 February 2009 16:35:56 sebb wrote: > > On 16/02/2009, Noel O'Brien <[email protected]> wrote: > > > On Monday 16 February 2009 15:42:46 sebb wrote: > > > > On 16/02/2009, Noel O'Brien <[email protected]> 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. 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. The BeanShell elements may be useful for prototyping. > Thanks for your help, > > Noel > > > > > Regards, > > > > > > Noel > > > > > > > > Regards, > > > > > Noel > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > >- 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] > > > > --------------------------------------------------------------------- > > 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]
