> -----Original Message----- > From: sebb [mailto:[email protected]] > Sent: quarta-feira, 23 de Junho de 2010 16:50 > 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 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 I specify in the sampler that I want to read N messages, I don't want the sampler to consume N+1, and worse only return N messages, and "swallow" one message. If one cares that all messages are consumed, he could use a future messageconsumer with nowait to assert that there are no messages left in the queue. > > > 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. Maybe other use cases would be consuming all the messages I can during a specific time? And then assert the number of received messages? Or can this be achieved with a loop consuming 1 message? > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
