jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: JMS help wanted: need use cases for queue subscriptions
Date Wed, 23 Jun 2010 15:21:41 GMT
2010/6/23 João Tiago Ferreira <joao.tiago.ferreira@novabase.pt>:
>> -----Original Message-----
>> From: sebb [mailto:sebbaz@gmail.com]
>> 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 <joao.tiago.ferreira@novabase.pt>:
>> > 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.

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.

Whether that would satisfy all the possible use-cases remains to be seen.

>>
>> > Best regards
>> >
>> > João Ferreira
>> >
>> >> -----Original Message-----
>> >> From: sebb [mailto:sebbaz@gmail.com]
>> >> 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-unsubscribe@jakarta.apache.org
>> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >>
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org


Mime
View raw message