This specific field is message consumption rate, i.e. no message per time window. So we would need something like:
<slow-consumer-threshold>10msg/minute</slow-consumer-threshold> etc... I don't mind either way, as a unit parameter or as part of the value. Either way, we don't need to break configuration to add this improvement. Cheers On Tue, Mar 7, 2017 at 4:11 PM, Clebert Suconic <[email protected]> wrote: > On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <[email protected]> > wrote: > > > > <slow-consumer-threshold time-unit="1m">10</slow-consumer-threshold> > > > > I would suggest something more akin to what was implemented for byte > > fields (i.e. support notation like "KB", "M", "gb", etc.). For example: > > > > <slow-consumer-threshold>10m</slow-consumer-threshold> > > > > or > > > > <slow-consumer-threshold>30s</slow-consumer-threshold> > > > > > > > +1000 > > > > > And default to whatever time-unit is used now. > > > > > > Justin > > > > > > ----- Original Message ----- > > From: "Jiri Danek" <[email protected]> > > To: [email protected] > > Sent: Tuesday, March 7, 2017 10:01:13 AM > > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream > > > > On Tue, Mar 7, 2017 at 4:23 PM, Martyn Taylor <[email protected]> > wrote: > > > > > Hi Jiri, > > > > > > Thanks for bringing this up again. > > > > > > One approach to this that avoids having to add new settings or change > the > > > default values of current config would be to add a unit parameter to > the > > > configuration element. For example > > > > > > <!-- 10 messages per 1 minute --> > > > <slow-consumer-threshold time-unit="1m">10</slow-consumer-threshold> > > > > > > This is just an example, but we could standardise across all > > configuraiton > > > options by just passing in "unit". > > > > > > This way users are free to express units that they are familiar with > > > (msg/s) for example is a typical measurement, however, it could be > > messages > > > per minute or what ever you want. > > > > > > Does this sound reasonable? > > > > > > > Hi, yes, that would resolve the usecase I had in mind in such a way that > > current configuration files stay compatible. Sorry for derailing the 2.x > > stream thread. I am looking forward to that release soonest. > > > > Best of wishes, > > > > > > > > > > Cheers > > > > > > On Tue, Mar 7, 2017 at 2:12 PM, Jiri Danek <[email protected]> wrote: > > > > > > > I somehow buried this thread, sorry... > > > > > > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic < > > > > [email protected] > > > > > wrote: > > > > > > > > > you're right.. I was just trying to understand Jiri's comment, and > > not > > > > > actually make an evaluation on the feature. > > > > > > > > > > > > > When I wrote the comment, I was confused about the units. I somehow > > > thought > > > > that both <slow-consumer-threshold> and <slow-consumer-check-period> > > were > > > > meant to be in minutes, but by some mistake it got coded in seconds > and > > > > then it was not possible to change it because of backwards > > > compatibility. I > > > > thought that 2.0.0 release could be a good point to make it right. > > > > > > > > In fact, I think that <slow-consumer-threshold> should be in minutes, > > > > because if it is in seconds, the lowest message rate that it is > > possible > > > to > > > > specify is 1 msg/s. I imagine it may be too high for some users who > > send > > > > very large messages or messages where processing of each takes a very > > > long > > > > time. Minutes as a unit would increase the range of possible values. > > > > > > > > I'll think more about this and either start a new thread, or wait for > > > Miro > > > > to start it (in case he feels the need to discuss the slow consumers > > > > feature in relation to the Jira he opened), or just leave it be. > > > > -- > > > > Jiří Daněk > > > > Messaging QA > > > > > > > > > > > > > > > -- > > Jiří Daněk > > Messaging QA > > > -- > Clebert Suconic >
