Prefetch fields in management UI

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Prefetch fields in management UI

Ben Hood
Hi all,

Does anybody know what the difference is on the per-queue view in the
management UI between the prefetch value in the details pane versus
the value reported in the list of consumers? I've appended a couple of
screenshots to better highlight the point (with and without the qos
sharing flag).

Cheers,

Ben

PS This is a 3.3.0/16B03/OSX 10.9.2 combo.

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Screenshot 2014-04-22 18.41.24.png (42K) Download Attachment
Screenshot 2014-04-22 18.41.46.png (42K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Prefetch fields in management UI

Ben Hood
On Tue, Apr 22, 2014 at 6:46 PM, Ben Hood <[hidden email]> wrote:
> Does anybody know what the difference is on the per-queue view in the
> management UI between the prefetch value in the details pane versus
> the value reported in the list of consumers? I've appended a couple of
> screenshots to better highlight the point (with and without the qos
> sharing flag).

I have a feeling that this might be a client issue. The screenshots I
sent were made using an the Go amqp driver - the official Java client
doesn't seem to have this issue. Sorry about the noise.
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Prefetch fields in management UI

Ben Hood
On Tue, Apr 22, 2014 at 7:19 PM, Ben Hood <[hidden email]> wrote:
> I have a feeling that this might be a client issue. The screenshots I
> sent were made using an the Go amqp driver - the official Java client
> doesn't seem to have this issue. Sorry about the noise.

Turns out this issue is reproducible with the official Java client,
but it might just be due to lack of RTFM. So qos does not appear to
take effect if the command is submitted after the call to subscribe to
a queue, with in the context of a single channel. So to fix this
issue, all I needed to do is to make sure that setting the prefetch
happens before subscribing to a queue. I never realized that egress
qos is order dependent - I had just assumed that that it is a
changeable value within the context of the limiter.

What puzzled me is that the same app running against 3.2.4 does not
(anecdotally) seem to care as much about the command order as the
current release. I probably need to re-read the documentation.
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Prefetch fields in management UI

Simon MacMullen-2
On 23/04/2014 00:21, Ben Hood wrote:
> So qos does not appear to
> take effect if the command is submitted after the call to subscribe to
> a queue, with in the context of a single channel. So to fix this
> issue, all I needed to do is to make sure that setting the prefetch
> happens before subscribing to a queue. I never realized that egress
> qos is order dependent - I had just assumed that that it is a
> changeable value within the context of the limiter.

Note that the semantics of qos have changed in 3.3.0:

http://www.rabbitmq.com/consumer-prefetch.html

Per-consumer prefetch will be fixed at the moment the consumer is
created. Per-channel prefetch can be changed after the fact, as before.
But it was never a great idea to do that since if you set qos after
consuming then the broker can deliver as many messages as it wants in
between the two commands, which is unlikely to be what you want.

Cheers, Simon
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Prefetch fields in management UI

Ben Hood
On Wed, Apr 23, 2014 at 9:08 AM, Simon MacMullen <[hidden email]> wrote:
> Note that the semantics of qos have changed in 3.3.0:
>
> http://www.rabbitmq.com/consumer-prefetch.html
>
> Per-consumer prefetch will be fixed at the moment the consumer is created.
> Per-channel prefetch can be changed after the fact, as before. But it was
> never a great idea to do that since if you set qos after consuming then the
> broker can deliver as many messages as it wants in between the two commands,
> which is unlikely to be what you want.

Yep, that all makes sense and the change in the scope of qos in 3.3 is
really good idea.

So the take home is that you could have an app with a bug in it
(issuing qos after the consume), then a pre-3.3 broker would mask this
issue for you. So app only then becomes really broken after upgrading
to 3.3.

But the fix is simple.

Cheers,

Ben
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss