> -----Original Message----- > From: sebb [mailto:[email protected]] > Sent: terça-feira, 22 de Junho de 2010 11:57 > To: JMeter Users List > Subject: Re: JMS Assertion?? > > On 21/06/2010, João Tiago Ferreira <[email protected]> > wrote: > > Hi > > > > Patch for JMS Queue receiver in > https://issues.apache.org/bugzilla/show_bug.cgi?id=49482 > > Thanks, I've had a brief look at the code. > > > The great difference from Topic Subscriber is the cleaning of > resources and is impossibility of choosing the client method to use. > > What do you mean - choosing the client method to use?
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#JMS_Subscriber Choose between Receiver.receive() and MessageListener.onMessage(). I use receive() > > > Instead of cleaning the Receivers in the end of the test they are > cleaned at the end of the sample. I had problems with the initial > approach, when running test with multiple clients, the 1st client was > receiving all the messages. This behavior worked in topics because the > delivery semantics are different publish/subscribe vs point-to-point. > > > AIUI, queues are supposed to have a single reader and one or more > writers. Is that correct? > > If so, then using multiple samplers for the same queue would mean that > the queue must be handed off between samplers, so only one uses it at > a time. > > I'm not sure that it makes sense for a single queue to be shared > between multiple threads. AIUI, you can have multiple writers and multiple readers but when a message is sent, only one reader will receive the message, in contrast with topics where all readers will receive it. When having multiple threads I think nothing guarantees that the message sent/generated by the 1st thread will be received by the 1st thread (this should be guaranteed using correlation(?)) . However if the tests are sequential and no threads are used, only one receiver will exist at a given moment. This will work for my requirements because I am more focused on functional testing, i.e guarantee that a message is generated for a specific queue after some action is executed... > > --------------------------------------------------------------------- > 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]
