You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jakarta.apache.org by bu...@apache.org on 2010/06/21 21:23:26 UTC
DO NOT REPLY [Bug 49482] New: JMS Queue Receiver
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
Summary: JMS Queue Receiver
Product: JMeter
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Main
AssignedTo: notifications@jakarta.apache.org
ReportedBy: jtjeferreira@gmail.com
Created an attachment (id=25626)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25626)
JMS Queue Receiver Sampler and GUI
Like there is a sampler for subscribing and publishing to topics, a receiver
for queues is of interest. Although the queue sender can be accomplished using
the JMS p2p sampler, the receiver cannot.
This was very inspired in the existing topic subscriber...
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution| |FIXED
--- Comment #12 from Sebb <se...@apache.org> 2010-07-05 08:38:11 EDT ---
OK, let's close this for now.
If further problems arise, please re-open with details.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #11 from João Ferreira <jt...@gmail.com> 2010-07-05 07:45:35 EDT ---
Hi sorry for taking so long but I was away.
As you said that alteration for stopping is enough for me. Thanks for the
support.
(In reply to comment #10)
> Nightl builds from 958003 have a new option on the Subscriber GUI which can be
> used to stop/start the connector between samples.
>
> Hopefully that will be enough.
>
> Please report how you get on.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #10 from Sebb <se...@apache.org> 2010-06-25 11:37:06 EDT ---
Nightl builds from 958003 have a new option on the Subscriber GUI which can be
used to stop/start the connector between samples.
Hopefully that will be enough.
Please report how you get on.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #9 from Sebb <se...@apache.org> 2010-06-24 06:55:58 EDT ---
(In reply to comment #8)
> Hi
>
> I'm testing the new trunk. However it seems it is not working either.
Works OK for me with Active MQ. I can share queued messages successfully
between samplers using the receive() method.
> Why not call org.apache.jmeter.protocol.jms.client.ReceiveSubscriber.close() in
> the end of the sample?
Because that will destroy the connection, which will have to be re-established.
Almost certain to lose messages between samples.
However, it might help to call stop() at the end, and start() at the beginning
of each sample.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #8 from João Ferreira <jt...@gmail.com> 2010-06-24 06:45:33 EDT ---
Hi
I'm testing the new trunk. However it seems it is not working either. I cant
give it much attention now, but I have set some debug messages and i think the
problem is now more JMS related. It looks like when 2 consumers are connected
(although not calling receive twice) the 2nd message is not received by the 2nd
consumer. I will investigate this later. The weird think is I cant reproduce
this problem all the time :s
Why not call org.apache.jmeter.protocol.jms.client.ReceiveSubscriber.close() in
the end of the sample? For example using something like
org.apache.jmeter.protocol.jms.client.ClientPool.removeClient(Closeable)?
(In reply to comment #7)
> I've uploaded a new nightly, r957393.
>
> This uses a different strategy for the receive() client option.
> Instead of running a background thread which polls for messages and stores them
> on a queue, the code now only fetches messages on demand.
>
> This should improve the behaviour with multiple samplers accessing the same
> queue.
>
> The onMessage() strategy is unchanged, so that is likely to cause problems when
> using Queues. However it should work fine for Topics.
>
> Perhaps you can try your test case with the new code?
>
> The nightly also includes better timeout handling.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #3 from Sebb <se...@apache.org> 2010-06-23 07:58:37 EDT ---
(In reply to comment #2)
> Hi
>
> (In reply to comment #1)
> > After generalising all the Topic and Queue interfaces, it turns out that the
> > current JMS Subscriber will just as easily support Queue names as well as Topic
> > names.
> >
> > These changes are in nightly builds from 957067.
> >
> > Any chance you could test against your JMS installation?
>
> The refactoring you did is very nice but the current lifecycle of the
> ReceiveSubscriber is not suited for queues semantics altought it works with
> topics.
>
> Consider the case where i have a testplan with 2 users and a queue subscriber
> waiting for 1 message.
Not sure I understand the real-life use case for this.
How do the users each get their message, and only theirs?
> The expected output was that each subscriber received 1
> message but what happens is that one subscriber receives both messages and the
> other none. This happens because the subscriber isn't closed after it received
> the expected number of messages.
>
> The patch i submitted considered this problem by closing the subscriber in the
> end of the sample instead of the end of the test as is implemented now. I used
> ClientPool.removeClient(this.RECEIVER) to achieve this.
There probably does need to be different behaviour for queues, but I'm not
convinced that is the way to go.
What should happen to messages sent to a queue when no sampler is active?
I think this needs to be discussed further on the JMeter user list.
> I think this behaviour can be used with topics due to their publish/subscribe
> semantics.
> A cosmetic note: rename some variables to abstract the transition from topics
> to destinations and subscriber to message consumer. Same applies to the name of
> the sampler and the labels of the GUI
Already in progress.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #2 from João Ferreira <jt...@gmail.com> 2010-06-23 07:22:20 EDT ---
Hi
(In reply to comment #1)
> After generalising all the Topic and Queue interfaces, it turns out that the
> current JMS Subscriber will just as easily support Queue names as well as Topic
> names.
>
> These changes are in nightly builds from 957067.
>
> Any chance you could test against your JMS installation?
The refactoring you did is very nice but the current lifecycle of the
ReceiveSubscriber is not suited for queues semantics altought it works with
topics.
Consider the case where i have a testplan with 2 users and a queue subscriber
waiting for 1 message. The expected output was that each subscriber received 1
message but what happens is that one subscriber receives both messages and the
other none. This happens because the subscriber isn't closed after it received
the expected number of messages.
The patch i submitted considered this problem by closing the subscriber in the
end of the sample instead of the end of the test as is implemented now. I used
ClientPool.removeClient(this.RECEIVER) to achieve this.
I think this behaviour can be used with topics due to their publish/subscribe
semantics.
A cosmetic note: rename some variables to abstract the transition from topics
to destinations and subscriber to message consumer. Same applies to the name of
the sampler and the labels of the GUI
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #4 from João Ferreira <jt...@gmail.com> 2010-06-23 09:15:24 EDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Hi
> >
> > (In reply to comment #1)
> > > After generalising all the Topic and Queue interfaces, it turns out that the
> > > current JMS Subscriber will just as easily support Queue names as well as Topic
> > > names.
> > >
> > > These changes are in nightly builds from 957067.
> > >
> > > Any chance you could test against your JMS installation?
> >
> > The refactoring you did is very nice but the current lifecycle of the
> > ReceiveSubscriber is not suited for queues semantics altought it works with
> > topics.
> >
> > Consider the case where i have a testplan with 2 users and a queue subscriber
> > waiting for 1 message.
>
> Not sure I understand the real-life use case for this.
> How do the users each get their message, and only theirs?
This use case isn't the best because i cant guarantee that each user gets their
message. However instead of having two parallel users, i could have two
sequential tests that invoke the application and waits for the message and the
queue and repeats.
The problem is that the 1st receiver sampler gets 2 messages and the 2nd
receiver none.
>
> > The expected output was that each subscriber received 1
> > message but what happens is that one subscriber receives both messages and the
> > other none. This happens because the subscriber isn't closed after it received
> > the expected number of messages.
> >
> > The patch i submitted considered this problem by closing the subscriber in the
> > end of the sample instead of the end of the test as is implemented now. I used
> > ClientPool.removeClient(this.RECEIVER) to achieve this.
>
> There probably does need to be different behaviour for queues, but I'm not
> convinced that is the way to go.
>
> What should happen to messages sent to a queue when no sampler is active?
The message stays in the queue, no problem... The next receiver will get it...
>
> I think this needs to be discussed further on the JMeter user list.
>
> > I think this behaviour can be used with topics due to their publish/subscribe
> > semantics.
>
> > A cosmetic note: rename some variables to abstract the transition from topics
> > to destinations and subscriber to message consumer. Same applies to the name of
> > the sampler and the labels of the GUI
>
> Already in progress.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #5 from João Ferreira <jt...@gmail.com> 2010-06-23 09:28:47 EDT ---
Created an attachment (id=25630)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25630)
Sample Testplan
Sample test plan that describes my use case
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #7 from Sebb <se...@apache.org> 2010-06-23 20:32:08 EDT ---
I've uploaded a new nightly, r957393.
This uses a different strategy for the receive() client option.
Instead of running a background thread which polls for messages and stores them
on a queue, the code now only fetches messages on demand.
This should improve the behaviour with multiple samplers accessing the same
queue.
The onMessage() strategy is unchanged, so that is likely to cause problems when
using Queues. However it should work fine for Topics.
Perhaps you can try your test case with the new code?
The nightly also includes better timeout handling.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Sebb <se...@apache.org> 2010-06-22 18:46:05 EDT ---
After generalising all the Topic and Queue interfaces, it turns out that the
current JMS Subscriber will just as easily support Queue names as well as Topic
names.
These changes are in nightly builds from 957067.
Any chance you could test against your JMS installation?
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org
DO NOT REPLY [Bug 49482] JMS Queue Receiver
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49482
--- Comment #6 from João Ferreira <jt...@gmail.com> 2010-06-23 09:32:03 EDT ---
Created an attachment (id=25631)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=25631)
Log of the execution of previous test plan
This log shows that the test plan is stopped waiting for the 2nd rceiver... I
then stop the test and the exception occurs when closing connection.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@jakarta.apache.org
For additional commands, e-mail: notifications-help@jakarta.apache.org