jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From João Tiago Ferreira <>
Subject RE: Jmeter JMS support for Tibco EMS
Date Fri, 18 Jun 2010 11:45:23 GMT

> -----Original Message-----
> From: sebb []
> Sent: sexta-feira, 18 de Junho de 2010 11:57
> To: JMeter Users List
> Subject: Re: Jmeter JMS support for Tibco EMS
> On 18/06/2010, João Tiago Ferreira <>
> wrote:
> > Hi. I dont think there are so many use cases.
> >
> >  First point is the sender of the message can't set the messageId. It
> is an identifier of the message generated by the JMS provider.
> I know.
> > Moreover two different messages can't have the same messageID, so I
> would say comparing "request:messageId == reply:messageId" makes no
> sense.
> It *can* make sense in "echo" mode:
> The sampler can send to a queue and then receive the original message
> from the same queue. Could be useful for checking queue throughput.
> In that case, *if* the correlationID is present of course one could
> use that instead.

Why not a different jms sampler for the "echo" mode?
We could have this "request-response" sampler to simulate a client that sends a request and
is expecting the response from the application being tested.
And another sampler that would allow that "echo" mode to test throughput by comparing request.messageID
== reply.messageID,

> >  Here is a nice explanation of the different JMS request response
> patterns [1].
> Does not work for  me - I get an empty page.
> >  So when you check the option "Use Request Message Id As Correlation
> Id" we are using the "JMS Message ID Pattern" where no correlationId is
> necessary to set in the request and in the receiver we should check for
> request:messageId == reply:correlationId instead of "request:messageId
> == reply:messageId"
> That relies on the response correlation ID being set to the request
> message ID - which does not happen automatically, as far as I can
> tell.

Correct. This the responsibility of the application being tested. But never is responsibility
of the JMS provider to set it...

> >  When you uncheck the "Use Request Message Id As Correlation Id" we
> are using the "JMS Correlation ID Pattern" and is necessary to set the
> correlatioId in the request and in the receiver we should check for
> "request:correlationId == reply:correlationId" as is implemented now.
> The service has to copy the correlationId from request to response.

Correct. Same as above

> Your use cases both rely on checking the response correlationId which
> it is assumed will be set from either the request correlationId or the
> requestMessageId.
> The person who raised the original Bug 46142 reported that the
> correlationId was null for JBoss, and the cited message thread says
> that the same problem happens with Weblogic.
> If the JMeter receiver only looks at the response correlationId, it
> seems this will cause problems for JBoss and Weblogic.
> So I think it is necessary to make the request and response fields
> independently selectable. I don't think on can satisfy everyone
> without.
> I've already done much of the work for this; it seems to work OK for
> ActiveMQ in "echo" mode at least.

It looks like the original bug was testing the "echo" mode. Then my idea of having different
samplers for different things, but of course they can reuse much code.

> >  Note: when I say "receiver" I mean the client side receiver, i.e the
> Jmeter receiver...
> >
> >  Thanks for support
> >
> >  João Ferreira
> >
> >
> >  [1]
> sgIDPatternforJMS.html
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message