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. Moreover two different messages can't have the same messageID, so I would say comparing "request:messageId == reply:messageId" makes no sense.
Here is a nice explanation of the different JMS request response patterns [1]. 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" 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. Note: when I say "receiver" I mean the client side receiver, i.e the Jmeter receiver... Thanks for support João Ferreira PS: I see that you have a wish to migrate your build tool to maven. If you want I could give some help, cause im a big fan of it, and would be easier to use Jmeter from 3rd party sources, for example JMeter plugin. [1] http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/interopjms/MsgIDPatternforJMS.html > -----Original Message----- > From: sebb [mailto:[email protected]] > Sent: sexta-feira, 18 de Junho de 2010 0:25 > To: JMeter Users List > Subject: Re: Jmeter JMS support for Tibco EMS > > > It looks like there are 4 options altogether, depending on which > fields to use to correlate the messages: > > * request field: messageId or correlationId > * response field: messageId or correlationId > > The current nightly code supports only the following 2 options: > > + request:messageId == reply:messageId > + request:correlationId == reply:correlationId > > However AIUI your use case is > > request:messageId == reply:correlationId > > which is not currently supported. > > I think the solution is to allow the request and response "match" > fields to be chosen independently. > > --------------------------------------------------------------------- > 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]
