> -----Original Message----- > From: sebb [mailto:[email protected]] > Sent: quarta-feira, 23 de Junho de 2010 16:22 > To: JMeter Users List > Subject: Re: JMS help wanted: need use cases for queue subscriptions > > 2010/6/23 João Tiago Ferreira <[email protected]>: > >> -----Original Message----- > >> From: sebb [mailto:[email protected]] > >> Sent: quarta-feira, 23 de Junho de 2010 15:00 > >> To: JMeter Users List > >> Subject: Re: JMS help wanted: need use cases for queue subscriptions > >> > >> 2010/6/23 João Tiago Ferreira <[email protected]>: > >> > Hi > >> > > >> > This requirement first appeared when testing an application that > >> generates a JMS message to a queue as the result of an action (not > >> necessarily a JMS request). > >> > >> OK. > >> > >> > The problem is the different semantics of queues and topics as > >> stated. While with topics the consumer can stay alive till the end > of > >> the test and not interfere with other tests, with queues they have > to > >> be closed because they will not enable the other consumers to > receive > >> the messages... > >> > > >> > My use case would require that several consumers can be > instantiated > >> by their samplers and their life cycle to be well managed so they > stop > >> receiving after they receive the specified number of messages. > >> > >> I meant, how does each queue consumer operate in the live situation, > >> not how JMeter does it currently. > >> > >> If the consumers all connect to the same queue, then there is no > >> guarantee which (if any) messages they will see. > >> How is this problem resolved in the live case? > > > > In the live case there is only one consumer, or if even several > consumers exist does not matter which one will receive it because they > will do the same task. However when doing functional tests I want to > guarantee that the consumers receive the message sent in the actual > test, so I can assert the data... > > In that case, just use a single thread with a single subscriber to > retrieve the messages singly in a loop, and assert against each one. > > JMeter threads are supposed to represent independent users. > It's not possible in general to ensure that samplers in different > threads execute in any particular relative order. > So even if the message queue were shared between samplers in different > threads, in general there is no guarantee which thread would get the > next message.
OK. But considering only single thread tests, if I have two different test cases and in both of them I want to assert the receiving of a JMS message in a queue, I can't achieve this currently. I think because the messageConsumer is closed to late. I tried using 2 threads groups and still no success. > > However, I do agree that the current behaviour is not ideal; even > within a single thread multiple subscribers to the same queue will > behave oddly. > > I suspect that each JMS queue needs to have its own internal queue > which can be handed off between samplers as needed. Internal queues? Can't just the sampler receive N messages and then shutdown? If there are messages still in the queues I can live with that... Btw other improvement would be timeouts in the consumer, but that is another issue... > > Whether that would satisfy all the possible use-cases remains to be > seen. > > >> > >> > Best regards > >> > > >> > João Ferreira > >> > > >> >> -----Original Message----- > >> >> From: sebb [mailto:[email protected]] > >> >> Sent: quarta-feira, 23 de Junho de 2010 13:14 > >> >> To: JMeter Users List > >> >> Subject: JMS help wanted: need use cases for queue subscriptions > >> >> > >> >> JMeter 2.3.4 supports JMS Topics for Publish and Subscribe. > >> >> > >> >> Most of the code will also work with Queues, however a message > sent > >> to > >> >> a queue can only be read once (unlike topics, which can be read > by > >> >> many users). > >> >> > >> >> So JMeter likely needs to behave differently when receiving > messages > >> >> from queues. > >> >> > >> >> In order to implement suitable behaviour, it would be very useful > to > >> >> have some typical use-cases. > >> >> > >> >> So if you would like to be able to test your JMS system with > JMeter, > >> >> please share brief details. > >> >> > >> >> ----------------------------------------------------------------- > --- > >> - > >> >> To unsubscribe, e-mail: jmeter-user- > [email protected] > >> >> For additional commands, e-mail: jmeter-user- > [email protected] > >> >> > >> > > >> > > >> > > >> > ------------------------------------------------------------------ > --- > >> > To unsubscribe, e-mail: [email protected] > >> > For additional commands, e-mail: jmeter-user- > [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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
