2010/6/23 João Tiago Ferreira <[email protected]>: > > >> -----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?
Yes, of course, but then further messages to the queue will be lost until the next sampler connects to the queue. Is that really what you want? > If there are messages still in the queues I can live with that... Maybe you can, but there will be other use-cases where that is not appropriate. That's why I started this thread... > Btw other improvement would be timeouts in the consumer, but that is another > issue... Already looking at that. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
