You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Martyn Taylor <mt...@redhat.com> on 2017/02/09 12:18:11 UTC
[DISCUSS] ActiveMQ Artemis 2.x stream
All,
As discussed in a previous thread [1] Artemis master has had a major bump
(due to major model refactor).
The great news is that the new model is more flexible and lends itself well
to 5.x features like Virtual Topics as well as being consistent across all
protocols. The not so good news is that this work required API breakages,
hence the major version bump.). This refactor work (mostly around the
addressing scheme [2]) is now completed.
The code base is now in a stable state, and as such, I'd like to start
thinking about doing a release off of master as an Apache Artemis 2.0.0 to
get the new changes into the hands of users.
I'd like to open discussion around this topic, does anyone have any
suggestions, or can think of anything that is needed before we go ahead
with a major release? This is the perfect time to do anything that could
break APIs, drop deprecated methods support, break data format etc...
Cheers
Martyn
[1]
http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html
[2] https://issues.apache.org/jira/browse/ARTEMIS-780
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Justin Bertram <jb...@apache.org>.
FWIW, I commented [1] on ARTEMIS-1001 regarding this issue to clear up a few things.
Additionally, I'm fine with adding time-unit notation parsing, but it's worth noting that IMO this isn't as pressing as the byte notation because multiplying by 60 is quite a bit simpler than multiplying by 1024.
Justin
[1] https://issues.apache.org/jira/browse/ARTEMIS-1001?focusedCommentId=15901252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15901252
----- Original Message -----
From: "Miroslav Novak" <mn...@redhat.com>
To: dev@activemq.apache.org
Sent: Wednesday, March 8, 2017 4:46:22 AM
Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Thanks Martyn, I just had this impression from the code and wanted to check it with you in [1] . Let's leave it as it is and not break things.
Mirek
[1] https://issues.apache.org/jira/browse/ARTEMIS-1001?focusedCommentId=15887539&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15887539
----- Original Message -----
> From: "Martyn Taylor" <mt...@redhat.com>
> To: dev@activemq.apache.org
> Sent: Wednesday, March 8, 2017 11:07:19 AM
> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>
> Mirek,
>
> I'd prefer not to change the default value, but instead make our
> configuration options include a units parameter. If we add a units
> parameter like discussed above users can specify however which way they'd
> like to time slice their window, changing it to only support 5 minutes
> might be great for you, but not so great for other users.
>
> I think this applies to many other configuration options where units are
> currently fixed. I don't think we need to break and API or configuration
> to resolve this, let's just extend it to give users more control.
>
> Cheers
> Martyn
>
> On Wed, Mar 8, 2017 at 6:57 AM, Miroslav Novak <mn...@redhat.com> wrote:
>
> > I would like only to change default value for attribute
> > "slow-consumer-check-period' from 5 seconds to 5 minutes. I believe it was
> > original intention. Calculating msg/s rate based on 5 second time window
> > might be very inaccurate.
>
>
> > Mirek
> >
> > ----- Original Message -----
> > > From: "Martyn Taylor" <mt...@redhat.com>
> > > To: dev@activemq.apache.org
> > > Sent: Tuesday, March 7, 2017 5:48:42 PM
> > > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
> > >
> > > 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 <
> > clebert.suconic@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jb...@apache.org>
> > > > 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" <jd...@redhat.com>
> > > > > To: dev@activemq.apache.org
> > > > > 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 <mt...@redhat.com>
> > > > 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 <jd...@redhat.com>
> > wrote:
> > > > > >
> > > > > > > I somehow buried this thread, sorry...
> > > > > > >
> > > > > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > > > > > clebert.suconic@gmail.com
> > > > > > > > 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
> > > >
> > >
> >
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Justin Bertram <jb...@apache.org>.
FWIW, I commented [1] on ARTEMIS-1001 regarding this issue to clear up a few things.
Additionally, I'm fine with adding time-unit notation parsing, but it's worth noting that IMO this isn't as pressing as the byte notation because multiplying by 60 is quite a bit simpler than multiplying by 1024.
Justin
[1] https://issues.apache.org/jira/browse/ARTEMIS-1001?focusedCommentId=15901252&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15901252
----- Original Message -----
From: "Miroslav Novak" <mn...@redhat.com>
To: dev@activemq.apache.org
Sent: Wednesday, March 8, 2017 4:46:22 AM
Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Thanks Martyn, I just had this impression from the code and wanted to check it with you in [1] . Let's leave it as it is and not break things.
Mirek
[1] https://issues.apache.org/jira/browse/ARTEMIS-1001?focusedCommentId=15887539&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15887539
----- Original Message -----
> From: "Martyn Taylor" <mt...@redhat.com>
> To: dev@activemq.apache.org
> Sent: Wednesday, March 8, 2017 11:07:19 AM
> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>
> Mirek,
>
> I'd prefer not to change the default value, but instead make our
> configuration options include a units parameter. If we add a units
> parameter like discussed above users can specify however which way they'd
> like to time slice their window, changing it to only support 5 minutes
> might be great for you, but not so great for other users.
>
> I think this applies to many other configuration options where units are
> currently fixed. I don't think we need to break and API or configuration
> to resolve this, let's just extend it to give users more control.
>
> Cheers
> Martyn
>
> On Wed, Mar 8, 2017 at 6:57 AM, Miroslav Novak <mn...@redhat.com> wrote:
>
> > I would like only to change default value for attribute
> > "slow-consumer-check-period' from 5 seconds to 5 minutes. I believe it was
> > original intention. Calculating msg/s rate based on 5 second time window
> > might be very inaccurate.
>
>
> > Mirek
> >
> > ----- Original Message -----
> > > From: "Martyn Taylor" <mt...@redhat.com>
> > > To: dev@activemq.apache.org
> > > Sent: Tuesday, March 7, 2017 5:48:42 PM
> > > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
> > >
> > > 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 <
> > clebert.suconic@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jb...@apache.org>
> > > > 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" <jd...@redhat.com>
> > > > > To: dev@activemq.apache.org
> > > > > 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 <mt...@redhat.com>
> > > > 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 <jd...@redhat.com>
> > wrote:
> > > > > >
> > > > > > > I somehow buried this thread, sorry...
> > > > > > >
> > > > > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > > > > > clebert.suconic@gmail.com
> > > > > > > > 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
> > > >
> > >
> >
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Miroslav Novak <mn...@redhat.com>.
Thanks Martyn, I just had this impression from the code and wanted to check it with you in [1] . Let's leave it as it is and not break things.
Mirek
[1] https://issues.apache.org/jira/browse/ARTEMIS-1001?focusedCommentId=15887539&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15887539
----- Original Message -----
> From: "Martyn Taylor" <mt...@redhat.com>
> To: dev@activemq.apache.org
> Sent: Wednesday, March 8, 2017 11:07:19 AM
> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>
> Mirek,
>
> I'd prefer not to change the default value, but instead make our
> configuration options include a units parameter. If we add a units
> parameter like discussed above users can specify however which way they'd
> like to time slice their window, changing it to only support 5 minutes
> might be great for you, but not so great for other users.
>
> I think this applies to many other configuration options where units are
> currently fixed. I don't think we need to break and API or configuration
> to resolve this, let's just extend it to give users more control.
>
> Cheers
> Martyn
>
> On Wed, Mar 8, 2017 at 6:57 AM, Miroslav Novak <mn...@redhat.com> wrote:
>
> > I would like only to change default value for attribute
> > "slow-consumer-check-period' from 5 seconds to 5 minutes. I believe it was
> > original intention. Calculating msg/s rate based on 5 second time window
> > might be very inaccurate.
>
>
> > Mirek
> >
> > ----- Original Message -----
> > > From: "Martyn Taylor" <mt...@redhat.com>
> > > To: dev@activemq.apache.org
> > > Sent: Tuesday, March 7, 2017 5:48:42 PM
> > > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
> > >
> > > 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 <
> > clebert.suconic@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jb...@apache.org>
> > > > 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" <jd...@redhat.com>
> > > > > To: dev@activemq.apache.org
> > > > > 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 <mt...@redhat.com>
> > > > 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 <jd...@redhat.com>
> > wrote:
> > > > > >
> > > > > > > I somehow buried this thread, sorry...
> > > > > > >
> > > > > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > > > > > clebert.suconic@gmail.com
> > > > > > > > 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
> > > >
> > >
> >
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Martyn Taylor <mt...@redhat.com>.
Mirek,
I'd prefer not to change the default value, but instead make our
configuration options include a units parameter. If we add a units
parameter like discussed above users can specify however which way they'd
like to time slice their window, changing it to only support 5 minutes
might be great for you, but not so great for other users.
I think this applies to many other configuration options where units are
currently fixed. I don't think we need to break and API or configuration
to resolve this, let's just extend it to give users more control.
Cheers
Martyn
On Wed, Mar 8, 2017 at 6:57 AM, Miroslav Novak <mn...@redhat.com> wrote:
> I would like only to change default value for attribute
> "slow-consumer-check-period' from 5 seconds to 5 minutes. I believe it was
> original intention. Calculating msg/s rate based on 5 second time window
> might be very inaccurate.
> Mirek
>
> ----- Original Message -----
> > From: "Martyn Taylor" <mt...@redhat.com>
> > To: dev@activemq.apache.org
> > Sent: Tuesday, March 7, 2017 5:48:42 PM
> > Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
> >
> > 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 <
> clebert.suconic@gmail.com>
> > wrote:
> >
> > > On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jb...@apache.org>
> > > 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" <jd...@redhat.com>
> > > > To: dev@activemq.apache.org
> > > > 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 <mt...@redhat.com>
> > > 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 <jd...@redhat.com>
> wrote:
> > > > >
> > > > > > I somehow buried this thread, sorry...
> > > > > >
> > > > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > > > > clebert.suconic@gmail.com
> > > > > > > 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
> > >
> >
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Miroslav Novak <mn...@redhat.com>.
I would like only to change default value for attribute "slow-consumer-check-period' from 5 seconds to 5 minutes. I believe it was original intention. Calculating msg/s rate based on 5 second time window might be very inaccurate.
Mirek
----- Original Message -----
> From: "Martyn Taylor" <mt...@redhat.com>
> To: dev@activemq.apache.org
> Sent: Tuesday, March 7, 2017 5:48:42 PM
> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>
> 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 <cl...@gmail.com>
> wrote:
>
> > On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jb...@apache.org>
> > 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" <jd...@redhat.com>
> > > To: dev@activemq.apache.org
> > > 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 <mt...@redhat.com>
> > 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 <jd...@redhat.com> wrote:
> > > >
> > > > > I somehow buried this thread, sorry...
> > > > >
> > > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > > > clebert.suconic@gmail.com
> > > > > > 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
> >
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Martyn Taylor <mt...@redhat.com>.
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 <cl...@gmail.com>
wrote:
> On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jb...@apache.org>
> 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" <jd...@redhat.com>
> > To: dev@activemq.apache.org
> > 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 <mt...@redhat.com>
> 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 <jd...@redhat.com> wrote:
> > >
> > > > I somehow buried this thread, sorry...
> > > >
> > > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > > clebert.suconic@gmail.com
> > > > > 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
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
On Tue, Mar 7, 2017 at 11:06 AM Justin Bertram <jb...@apache.org> 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" <jd...@redhat.com>
> To: dev@activemq.apache.org
> 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 <mt...@redhat.com> 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 <jd...@redhat.com> wrote:
> >
> > > I somehow buried this thread, sorry...
> > >
> > > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > > clebert.suconic@gmail.com
> > > > 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
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Justin Bertram <jb...@apache.org>.
> <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>
And default to whatever time-unit is used now.
Justin
----- Original Message -----
From: "Jiri Danek" <jd...@redhat.com>
To: dev@activemq.apache.org
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 <mt...@redhat.com> 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 <jd...@redhat.com> wrote:
>
> > I somehow buried this thread, sorry...
> >
> > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > clebert.suconic@gmail.com
> > > 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
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Jiri Danek <jd...@redhat.com>.
On Tue, Mar 7, 2017 at 4:23 PM, Martyn Taylor <mt...@redhat.com> 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 <jd...@redhat.com> wrote:
>
> > I somehow buried this thread, sorry...
> >
> > On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> > clebert.suconic@gmail.com
> > > 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
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Martyn Taylor <mt...@redhat.com>.
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?
Cheers
On Tue, Mar 7, 2017 at 2:12 PM, Jiri Danek <jd...@redhat.com> wrote:
> I somehow buried this thread, sorry...
>
> On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <
> clebert.suconic@gmail.com
> > 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
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Jiri Danek <jd...@redhat.com>.
I somehow buried this thread, sorry...
On Fri, Feb 10, 2017 at 11:54 PM, Clebert Suconic <clebert.suconic@gmail.com
> 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
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Martyn Taylor <mt...@redhat.com>.
Franz,
Contributions to documentation is always welcomed :). A scan of the
persistence layer and journal docs would be really useful. Thanks
On Tue, Mar 7, 2017 at 12:30 PM, nigro_franz <ni...@gmail.com> wrote:
> An awesome work Clebert!
> And to everyone that has made this master filled of such great stuff :)
> Martyn, do u need an hand on the doc?
> In particular the journal type part is something that I was pretty involved
> :P
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.
> nabble.com/DISCUSS-ActiveMQ-Artemis-2-x-stream-tp4721815p4723170.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by nigro_franz <ni...@gmail.com>.
Thanks Clebert!!!
Yes and I'll ask if makes sense to add something about the datasync option
too
--
View this message in context: http://activemq.2283324.n4.nabble.com/DISCUSS-ActiveMQ-Artemis-2-x-stream-tp4721815p4723306.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by nigro_franz <ni...@gmail.com>.
Cool
eheheh get some rest mate!!! :)
--
View this message in context: http://activemq.2283324.n4.nabble.com/DISCUSS-ActiveMQ-Artemis-2-x-stream-tp4721815p4723175.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
Adding mmap journal to the docs is a great idea.
Also make sure the configs are current on the docs.
I won't do any work today (beyond this email :) )
Will help out tomorrow.
On Tue, Mar 7, 2017 at 7:36 AM nigro_franz <ni...@gmail.com> wrote:
> An awesome work Clebert!
> And to everyone that has made this master filled of such great stuff :)
> Martyn, do u need an hand on the doc?
> In particular the journal type part is something that I was pretty involved
> :P
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/DISCUSS-ActiveMQ-Artemis-2-x-stream-tp4721815p4723170.html
> Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
>
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by nigro_franz <ni...@gmail.com>.
An awesome work Clebert!
And to everyone that has made this master filled of such great stuff :)
Martyn, do u need an hand on the doc?
In particular the journal type part is something that I was pretty involved
:P
--
View this message in context: http://activemq.2283324.n4.nabble.com/DISCUSS-ActiveMQ-Artemis-2-x-stream-tp4721815p4723170.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Martyn Taylor <mt...@redhat.com>.
Great work Clebert. I know this was a long hard slog. I'm going to send a
2.0.0 HEADSUP later today. I'm really excited to get all the great stuff
we've been doing on master into the hands of users.
I think now is a good time to revisit our documentation and examples to
ensure everything is up to date. I'm going to spend some time on this
today and tomorrow.
On Mon, Mar 6, 2017 at 4:13 PM, Clebert Suconic <cl...@gmail.com>
wrote:
> As you guys have seen, my work now arrived on master.
>
> Any further improvements now won't break any compatibility or anything.
>
> After this I think it's time to put something out and keep working on
> master as usual.
>
> On Fri, Feb 10, 2017 at 5:56 PM, Clebert Suconic
> <cl...@gmail.com> wrote:
> > although maybe giving this power to the user may change certain
> > semantics? things that are supposed to run fast could eventually take
> > much longer.
> >
> >
> > But the user would be in control.
> >
> >
> > Dunno, that's splitting the conversation on the 2.x discussion already.
> >
> > On Fri, Feb 10, 2017 at 5:54 PM, Clebert Suconic
> > <cl...@gmail.com> wrote:
> >>> The two properties are pretty straight-forward, and I personally don't
> see how making them use the same time unit makes things simpler. Granting
> such
> >>
> >> you're right.. I was just trying to understand Jiri's comment, and not
> >> actually make an evaluation on the feature.
> >>
> >> <idea> If we were to make any changes, I would change all properties
> >> that refer to time to also include the time unit on them. That way the
> >> user would be more free to make any changes. </idea>
> >>
> >>
> >>
> >> Example: <timeout>5s</timeout>
> >>
> >>
> >>
> >>
> >> Just an idea though!
> >>
> >>
> >>
> >> If not, I would keep it as is... as it wouldn't bring much value
> otherwise.
> >
> >
> >
> > --
> > Clebert Suconic
>
>
>
> --
> Clebert Suconic
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
As you guys have seen, my work now arrived on master.
Any further improvements now won't break any compatibility or anything.
After this I think it's time to put something out and keep working on
master as usual.
On Fri, Feb 10, 2017 at 5:56 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> although maybe giving this power to the user may change certain
> semantics? things that are supposed to run fast could eventually take
> much longer.
>
>
> But the user would be in control.
>
>
> Dunno, that's splitting the conversation on the 2.x discussion already.
>
> On Fri, Feb 10, 2017 at 5:54 PM, Clebert Suconic
> <cl...@gmail.com> wrote:
>>> The two properties are pretty straight-forward, and I personally don't see how making them use the same time unit makes things simpler. Granting such
>>
>> you're right.. I was just trying to understand Jiri's comment, and not
>> actually make an evaluation on the feature.
>>
>> <idea> If we were to make any changes, I would change all properties
>> that refer to time to also include the time unit on them. That way the
>> user would be more free to make any changes. </idea>
>>
>>
>>
>> Example: <timeout>5s</timeout>
>>
>>
>>
>>
>> Just an idea though!
>>
>>
>>
>> If not, I would keep it as is... as it wouldn't bring much value otherwise.
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
although maybe giving this power to the user may change certain
semantics? things that are supposed to run fast could eventually take
much longer.
But the user would be in control.
Dunno, that's splitting the conversation on the 2.x discussion already.
On Fri, Feb 10, 2017 at 5:54 PM, Clebert Suconic
<cl...@gmail.com> wrote:
>> The two properties are pretty straight-forward, and I personally don't see how making them use the same time unit makes things simpler. Granting such
>
> you're right.. I was just trying to understand Jiri's comment, and not
> actually make an evaluation on the feature.
>
> <idea> If we were to make any changes, I would change all properties
> that refer to time to also include the time unit on them. That way the
> user would be more free to make any changes. </idea>
>
>
>
> Example: <timeout>5s</timeout>
>
>
>
>
> Just an idea though!
>
>
>
> If not, I would keep it as is... as it wouldn't bring much value otherwise.
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
> The two properties are pretty straight-forward, and I personally don't see how making them use the same time unit makes things simpler. Granting such
you're right.. I was just trying to understand Jiri's comment, and not
actually make an evaluation on the feature.
<idea> If we were to make any changes, I would change all properties
that refer to time to also include the time unit on them. That way the
user would be more free to make any changes. </idea>
Example: <timeout>5s</timeout>
Just an idea though!
If not, I would keep it as is... as it wouldn't bring much value otherwise.
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Justin Bertram <jb...@apache.org>.
The <slow-consumer-threshold> property configures how many messages-per-second a consumer needs to ack before it will be considered "slow."
The <slow-consumer-check-period> property configures how many minutes to wait between checks for "slow" consumers.
The two properties are pretty straight-forward, and I personally don't see how making them use the same time unit makes things simpler. Granting such a change does make things marginally more simple, is that sufficient to justify the code change, documentation change, and the likely questions when things don't work like 1.x users expect?
If we really wanted to make this change then I'd recommend changing <slow-consumer-check-period> to be in seconds as that would be the simpler code change, and that change would have a smaller impact on users who are actually configuring this and who may not actually notice the different semantics. For example, checking for slow consumers every 3 seconds rather than every 3 minutes would have less of an impact than the potential message build-up you'd have if your slow consumers were calculated at 5 messages-per-minute rather than 5 messages-per-second.
Justin
----- Original Message -----
From: "Clebert Suconic" <cl...@gmail.com>
To: dev@activemq.apache.org
Sent: Friday, February 10, 2017 4:07:14 PM
Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
although we could deprecate this xml tag, and add a new one with some
creative name... add exceptions on the logs.. what would make it
suitable for even a minor update, on which case this would bee a
regular issue.
On Fri, Feb 10, 2017 at 5:06 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> I guess it's just simplification? one is in seconds, the other is in minutes?
>
> It seems something we should fix.. but it needs to be done on a major
> release. (it would break minor updates).
>
> On Fri, Feb 10, 2017 at 4:58 PM, Justin Bertram <jb...@apache.org> wrote:
>> What's the use-case for needing to "align" <slow-consumer-threshold> and <slow-consumer-check-period>?
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jiri Danek" <jd...@redhat.com>
>> To: dev@activemq.apache.org
>> Sent: Friday, February 10, 2017 3:26:01 PM
>> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>>
>> On Thu, Feb 9, 2017 at 1:18 PM, Martyn Taylor <mt...@redhat.com> wrote:
>>
>>> I'd like to open discussion around this topic, does anyone have any
>>> suggestions, or can think of anything that is needed before we go ahead
>>> with a major release? This is the perfect time to do anything that could
>>> break APIs, drop deprecated methods support, break data format etc...
>>>
>>
>> What about changing units on config option
>>
>> <slow-consumer-threshold>100</slow-consumer-threshold>
>>
>> currently it is in messages/second, I suggest using messages/minute, to
>> align it with
>>
>> <slow-consumer-check-period>5</slow-consumer-check-period>
>>
>> which is in minutes.
>>
>> --
>> Jiří Daněk
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
although we could deprecate this xml tag, and add a new one with some
creative name... add exceptions on the logs.. what would make it
suitable for even a minor update, on which case this would bee a
regular issue.
On Fri, Feb 10, 2017 at 5:06 PM, Clebert Suconic
<cl...@gmail.com> wrote:
> I guess it's just simplification? one is in seconds, the other is in minutes?
>
> It seems something we should fix.. but it needs to be done on a major
> release. (it would break minor updates).
>
> On Fri, Feb 10, 2017 at 4:58 PM, Justin Bertram <jb...@apache.org> wrote:
>> What's the use-case for needing to "align" <slow-consumer-threshold> and <slow-consumer-check-period>?
>>
>>
>> Justin
>>
>> ----- Original Message -----
>> From: "Jiri Danek" <jd...@redhat.com>
>> To: dev@activemq.apache.org
>> Sent: Friday, February 10, 2017 3:26:01 PM
>> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>>
>> On Thu, Feb 9, 2017 at 1:18 PM, Martyn Taylor <mt...@redhat.com> wrote:
>>
>>> I'd like to open discussion around this topic, does anyone have any
>>> suggestions, or can think of anything that is needed before we go ahead
>>> with a major release? This is the perfect time to do anything that could
>>> break APIs, drop deprecated methods support, break data format etc...
>>>
>>
>> What about changing units on config option
>>
>> <slow-consumer-threshold>100</slow-consumer-threshold>
>>
>> currently it is in messages/second, I suggest using messages/minute, to
>> align it with
>>
>> <slow-consumer-check-period>5</slow-consumer-check-period>
>>
>> which is in minutes.
>>
>> --
>> Jiří Daněk
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
I guess it's just simplification? one is in seconds, the other is in minutes?
It seems something we should fix.. but it needs to be done on a major
release. (it would break minor updates).
On Fri, Feb 10, 2017 at 4:58 PM, Justin Bertram <jb...@apache.org> wrote:
> What's the use-case for needing to "align" <slow-consumer-threshold> and <slow-consumer-check-period>?
>
>
> Justin
>
> ----- Original Message -----
> From: "Jiri Danek" <jd...@redhat.com>
> To: dev@activemq.apache.org
> Sent: Friday, February 10, 2017 3:26:01 PM
> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>
> On Thu, Feb 9, 2017 at 1:18 PM, Martyn Taylor <mt...@redhat.com> wrote:
>
>> I'd like to open discussion around this topic, does anyone have any
>> suggestions, or can think of anything that is needed before we go ahead
>> with a major release? This is the perfect time to do anything that could
>> break APIs, drop deprecated methods support, break data format etc...
>>
>
> What about changing units on config option
>
> <slow-consumer-threshold>100</slow-consumer-threshold>
>
> currently it is in messages/second, I suggest using messages/minute, to
> align it with
>
> <slow-consumer-check-period>5</slow-consumer-check-period>
>
> which is in minutes.
>
> --
> Jiří Daněk
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Justin Bertram <jb...@apache.org>.
What's the use-case for needing to "align" <slow-consumer-threshold> and <slow-consumer-check-period>?
Justin
----- Original Message -----
From: "Jiri Danek" <jd...@redhat.com>
To: dev@activemq.apache.org
Sent: Friday, February 10, 2017 3:26:01 PM
Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
On Thu, Feb 9, 2017 at 1:18 PM, Martyn Taylor <mt...@redhat.com> wrote:
> I'd like to open discussion around this topic, does anyone have any
> suggestions, or can think of anything that is needed before we go ahead
> with a major release? This is the perfect time to do anything that could
> break APIs, drop deprecated methods support, break data format etc...
>
What about changing units on config option
<slow-consumer-threshold>100</slow-consumer-threshold>
currently it is in messages/second, I suggest using messages/minute, to
align it with
<slow-consumer-check-period>5</slow-consumer-check-period>
which is in minutes.
--
Jiří Daněk
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Jiri Danek <jd...@redhat.com>.
On Thu, Feb 9, 2017 at 1:18 PM, Martyn Taylor <mt...@redhat.com> wrote:
> I'd like to open discussion around this topic, does anyone have any
> suggestions, or can think of anything that is needed before we go ahead
> with a major release? This is the perfect time to do anything that could
> break APIs, drop deprecated methods support, break data format etc...
>
What about changing units on config option
<slow-consumer-threshold>100</slow-consumer-threshold>
currently it is in messages/second, I suggest using messages/minute, to
align it with
<slow-consumer-check-period>5</slow-consumer-check-period>
which is in minutes.
--
Jiří Daněk
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
... also.. it would be nice to have a new webiste frontpage by the
time we are 2.0 on Artemis... :/
On Thu, Feb 9, 2017 at 8:57 AM, Clebert Suconic
<cl...@gmail.com> wrote:
> I am doing some refactoring on the encoding of messages...
>
>
> Currently ServerMessage and ClientMessage are too tight with Queue and
> the core client, requiring us to always convert messages through the
> core message.
>
>
> That is, if you receive a Message in OpenWire, it is converted back to
> the core-message through the converters and when a client comes, it
> will convert back to openwire. (same will go through any other
> protocols).
>
>
>
> I have started this on a personal branch, and I believe I will done in
> 2 weeks and half time, making good progress...
>
>
>
> I will open a dev/DISCUSS thread some time (I believe I had started
> one last year already).
>
>
>
> clebert
>
> On Thu, Feb 9, 2017 at 7:18 AM, Martyn Taylor <mt...@redhat.com> wrote:
>> All,
>>
>> As discussed in a previous thread [1] Artemis master has had a major bump
>> (due to major model refactor).
>>
>> The great news is that the new model is more flexible and lends itself well
>> to 5.x features like Virtual Topics as well as being consistent across all
>> protocols. The not so good news is that this work required API breakages,
>> hence the major version bump.). This refactor work (mostly around the
>> addressing scheme [2]) is now completed.
>>
>> The code base is now in a stable state, and as such, I'd like to start
>> thinking about doing a release off of master as an Apache Artemis 2.0.0 to
>> get the new changes into the hands of users.
>>
>> I'd like to open discussion around this topic, does anyone have any
>> suggestions, or can think of anything that is needed before we go ahead
>> with a major release? This is the perfect time to do anything that could
>> break APIs, drop deprecated methods support, break data format etc...
>>
>> Cheers
>> Martyn
>>
>> [1]
>> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html
>>
>> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
>
>
>
> --
> Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
I am doing some refactoring on the encoding of messages...
Currently ServerMessage and ClientMessage are too tight with Queue and
the core client, requiring us to always convert messages through the
core message.
That is, if you receive a Message in OpenWire, it is converted back to
the core-message through the converters and when a client comes, it
will convert back to openwire. (same will go through any other
protocols).
I have started this on a personal branch, and I believe I will done in
2 weeks and half time, making good progress...
I will open a dev/DISCUSS thread some time (I believe I had started
one last year already).
clebert
On Thu, Feb 9, 2017 at 7:18 AM, Martyn Taylor <mt...@redhat.com> wrote:
> All,
>
> As discussed in a previous thread [1] Artemis master has had a major bump
> (due to major model refactor).
>
> The great news is that the new model is more flexible and lends itself well
> to 5.x features like Virtual Topics as well as being consistent across all
> protocols. The not so good news is that this work required API breakages,
> hence the major version bump.). This refactor work (mostly around the
> addressing scheme [2]) is now completed.
>
> The code base is now in a stable state, and as such, I'd like to start
> thinking about doing a release off of master as an Apache Artemis 2.0.0 to
> get the new changes into the hands of users.
>
> I'd like to open discussion around this topic, does anyone have any
> suggestions, or can think of anything that is needed before we go ahead
> with a major release? This is the perfect time to do anything that could
> break APIs, drop deprecated methods support, break data format etc...
>
> Cheers
> Martyn
>
> [1]
> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html
>
> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
the encoding won't change that at all. The XML is using a producer to
send to import to the broker.. not dealing directly with the journal..
so it shouldn't affect it.
On Thu, Feb 9, 2017 at 3:24 PM, Christopher Shannon
<ch...@gmail.com> wrote:
> Agreed that stuff like a new plugin API shouldn't break anything. Things
> like that should hopefully just be enhancements and old public APIs would
> still work in Artemis.
>
> Also, related to our other thread on importing data, it might be nice to
> have a first version of the KahaDB exporter to Artemis XML done in time for
> version 2.0.0. Not sure how the refactoring of encoding of messages will
> effect that.
>
> What I have so far is here:
> https://github.com/cshannon/activemq-cli-tools/tree/queueExportTest
>
> It's still very rough and isn't done yet but so far I have a unit test test
> that does the following:
>
> -writes 10 text messages to a Queue in a KahaDB store
> -exports the 10 messages to XML
> -creates a new Artemis broker and imports the XML into the Artemis store
> -then creates a new JMS consumer and consumes all 10 messages from the
> Artemis broker
>
>
> On Thu, Feb 9, 2017 at 12:57 PM, Clebert Suconic <cl...@gmail.com>
> wrote:
>
>> I don't think it would break the API, it would be an addition.. not
>> breaking anything..
>>
>>
>> I would still support the current APIs we have now...
>>
>>
>> however the refactoring I'm doing will:
>>
>>
>> - Break how Interceptors work...
>> - Make the possibility of interacting of message bodies and properties
>> easier (It should make it actually fairly easy to implement anything
>> around Message types)
>> - Break the journal
>>
>>
>> Once the pure encoding is implemented, adding an API around
>> intercepting messages at the broker level should be easier. I don't
>> think that should break anything.
>>
>>
>> I'm not talking about scheduling the release here (if it should or not
>> go on the 2.0).. just what I think in technical terms regarding
>> breaking the APIs.
>>
>> On Thu, Feb 9, 2017 at 12:03 PM, Matt Pavlovich <ma...@gmail.com>
>> wrote:
>> > Martyn-
>> >
>> > I think an important API breakage issue is plugin support.
>> >
>> > -Matt
>> >
>> >
>> >
>> > On 2/9/17 6:18 AM, Martyn Taylor wrote:
>> >>
>> >> All,
>> >>
>> >> As discussed in a previous thread [1] Artemis master has had a major
>> bump
>> >> (due to major model refactor).
>> >>
>> >> The great news is that the new model is more flexible and lends itself
>> >> well
>> >> to 5.x features like Virtual Topics as well as being consistent across
>> all
>> >> protocols. The not so good news is that this work required API
>> breakages,
>> >> hence the major version bump.). This refactor work (mostly around the
>> >> addressing scheme [2]) is now completed.
>> >>
>> >> The code base is now in a stable state, and as such, I'd like to start
>> >> thinking about doing a release off of master as an Apache Artemis 2.0.0
>> to
>> >> get the new changes into the hands of users.
>> >>
>> >> I'd like to open discussion around this topic, does anyone have any
>> >> suggestions, or can think of anything that is needed before we go ahead
>> >> with a major release? This is the perfect time to do anything that could
>> >> break APIs, drop deprecated methods support, break data format etc...
>> >>
>> >> Cheers
>> >> Martyn
>> >>
>> >> [1]
>> >>
>> >> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-
>> addressing-improvements-JMS-component-removal-and-
>> potential-2-0-0-td4719262.html
>> >>
>> >> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
>> >>
>> >
>>
>>
>>
>> --
>> Clebert Suconic
>>
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Christopher Shannon <ch...@gmail.com>.
Agreed that stuff like a new plugin API shouldn't break anything. Things
like that should hopefully just be enhancements and old public APIs would
still work in Artemis.
Also, related to our other thread on importing data, it might be nice to
have a first version of the KahaDB exporter to Artemis XML done in time for
version 2.0.0. Not sure how the refactoring of encoding of messages will
effect that.
What I have so far is here:
https://github.com/cshannon/activemq-cli-tools/tree/queueExportTest
It's still very rough and isn't done yet but so far I have a unit test test
that does the following:
-writes 10 text messages to a Queue in a KahaDB store
-exports the 10 messages to XML
-creates a new Artemis broker and imports the XML into the Artemis store
-then creates a new JMS consumer and consumes all 10 messages from the
Artemis broker
On Thu, Feb 9, 2017 at 12:57 PM, Clebert Suconic <cl...@gmail.com>
wrote:
> I don't think it would break the API, it would be an addition.. not
> breaking anything..
>
>
> I would still support the current APIs we have now...
>
>
> however the refactoring I'm doing will:
>
>
> - Break how Interceptors work...
> - Make the possibility of interacting of message bodies and properties
> easier (It should make it actually fairly easy to implement anything
> around Message types)
> - Break the journal
>
>
> Once the pure encoding is implemented, adding an API around
> intercepting messages at the broker level should be easier. I don't
> think that should break anything.
>
>
> I'm not talking about scheduling the release here (if it should or not
> go on the 2.0).. just what I think in technical terms regarding
> breaking the APIs.
>
> On Thu, Feb 9, 2017 at 12:03 PM, Matt Pavlovich <ma...@gmail.com>
> wrote:
> > Martyn-
> >
> > I think an important API breakage issue is plugin support.
> >
> > -Matt
> >
> >
> >
> > On 2/9/17 6:18 AM, Martyn Taylor wrote:
> >>
> >> All,
> >>
> >> As discussed in a previous thread [1] Artemis master has had a major
> bump
> >> (due to major model refactor).
> >>
> >> The great news is that the new model is more flexible and lends itself
> >> well
> >> to 5.x features like Virtual Topics as well as being consistent across
> all
> >> protocols. The not so good news is that this work required API
> breakages,
> >> hence the major version bump.). This refactor work (mostly around the
> >> addressing scheme [2]) is now completed.
> >>
> >> The code base is now in a stable state, and as such, I'd like to start
> >> thinking about doing a release off of master as an Apache Artemis 2.0.0
> to
> >> get the new changes into the hands of users.
> >>
> >> I'd like to open discussion around this topic, does anyone have any
> >> suggestions, or can think of anything that is needed before we go ahead
> >> with a major release? This is the perfect time to do anything that could
> >> break APIs, drop deprecated methods support, break data format etc...
> >>
> >> Cheers
> >> Martyn
> >>
> >> [1]
> >>
> >> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-
> addressing-improvements-JMS-component-removal-and-
> potential-2-0-0-td4719262.html
> >>
> >> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
> >>
> >
>
>
>
> --
> Clebert Suconic
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Clebert Suconic <cl...@gmail.com>.
I don't think it would break the API, it would be an addition.. not
breaking anything..
I would still support the current APIs we have now...
however the refactoring I'm doing will:
- Break how Interceptors work...
- Make the possibility of interacting of message bodies and properties
easier (It should make it actually fairly easy to implement anything
around Message types)
- Break the journal
Once the pure encoding is implemented, adding an API around
intercepting messages at the broker level should be easier. I don't
think that should break anything.
I'm not talking about scheduling the release here (if it should or not
go on the 2.0).. just what I think in technical terms regarding
breaking the APIs.
On Thu, Feb 9, 2017 at 12:03 PM, Matt Pavlovich <ma...@gmail.com> wrote:
> Martyn-
>
> I think an important API breakage issue is plugin support.
>
> -Matt
>
>
>
> On 2/9/17 6:18 AM, Martyn Taylor wrote:
>>
>> All,
>>
>> As discussed in a previous thread [1] Artemis master has had a major bump
>> (due to major model refactor).
>>
>> The great news is that the new model is more flexible and lends itself
>> well
>> to 5.x features like Virtual Topics as well as being consistent across all
>> protocols. The not so good news is that this work required API breakages,
>> hence the major version bump.). This refactor work (mostly around the
>> addressing scheme [2]) is now completed.
>>
>> The code base is now in a stable state, and as such, I'd like to start
>> thinking about doing a release off of master as an Apache Artemis 2.0.0 to
>> get the new changes into the hands of users.
>>
>> I'd like to open discussion around this topic, does anyone have any
>> suggestions, or can think of anything that is needed before we go ahead
>> with a major release? This is the perfect time to do anything that could
>> break APIs, drop deprecated methods support, break data format etc...
>>
>> Cheers
>> Martyn
>>
>> [1]
>>
>> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html
>>
>> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
>>
>
--
Clebert Suconic
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Matt Pavlovich <ma...@gmail.com>.
Justin-
Here are the notes from before the holidays:
https://issues.apache.org/jira/browse/ARTEMIS-898
It shouldn't break customer facing APIs. Just depends on your view of
versioning and if service-side change should result in a major rev bump
as well.
-Matt
On 2/9/17 11:08 AM, Justin Bertram wrote:
> Can you elaborate on that, Matt? What exactly do you mean by "plugin support"? What user-facing APIs would necessarily break?
>
>
> Justin
>
> ----- Original Message -----
> From: "Matt Pavlovich" <ma...@gmail.com>
> To: dev@activemq.apache.org
> Sent: Thursday, February 9, 2017 11:03:31 AM
> Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
>
> Martyn-
>
> I think an important API breakage issue is plugin support.
>
> -Matt
>
>
> On 2/9/17 6:18 AM, Martyn Taylor wrote:
>> All,
>>
>> As discussed in a previous thread [1] Artemis master has had a major bump
>> (due to major model refactor).
>>
>> The great news is that the new model is more flexible and lends itself well
>> to 5.x features like Virtual Topics as well as being consistent across all
>> protocols. The not so good news is that this work required API breakages,
>> hence the major version bump.). This refactor work (mostly around the
>> addressing scheme [2]) is now completed.
>>
>> The code base is now in a stable state, and as such, I'd like to start
>> thinking about doing a release off of master as an Apache Artemis 2.0.0 to
>> get the new changes into the hands of users.
>>
>> I'd like to open discussion around this topic, does anyone have any
>> suggestions, or can think of anything that is needed before we go ahead
>> with a major release? This is the perfect time to do anything that could
>> break APIs, drop deprecated methods support, break data format etc...
>>
>> Cheers
>> Martyn
>>
>> [1]
>> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html
>>
>> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
>>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Justin Bertram <jb...@apache.org>.
Can you elaborate on that, Matt? What exactly do you mean by "plugin support"? What user-facing APIs would necessarily break?
Justin
----- Original Message -----
From: "Matt Pavlovich" <ma...@gmail.com>
To: dev@activemq.apache.org
Sent: Thursday, February 9, 2017 11:03:31 AM
Subject: Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Martyn-
I think an important API breakage issue is plugin support.
-Matt
On 2/9/17 6:18 AM, Martyn Taylor wrote:
> All,
>
> As discussed in a previous thread [1] Artemis master has had a major bump
> (due to major model refactor).
>
> The great news is that the new model is more flexible and lends itself well
> to 5.x features like Virtual Topics as well as being consistent across all
> protocols. The not so good news is that this work required API breakages,
> hence the major version bump.). This refactor work (mostly around the
> addressing scheme [2]) is now completed.
>
> The code base is now in a stable state, and as such, I'd like to start
> thinking about doing a release off of master as an Apache Artemis 2.0.0 to
> get the new changes into the hands of users.
>
> I'd like to open discussion around this topic, does anyone have any
> suggestions, or can think of anything that is needed before we go ahead
> with a major release? This is the perfect time to do anything that could
> break APIs, drop deprecated methods support, break data format etc...
>
> Cheers
> Martyn
>
> [1]
> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html
>
> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
>
Re: [DISCUSS] ActiveMQ Artemis 2.x stream
Posted by Matt Pavlovich <ma...@gmail.com>.
Martyn-
I think an important API breakage issue is plugin support.
-Matt
On 2/9/17 6:18 AM, Martyn Taylor wrote:
> All,
>
> As discussed in a previous thread [1] Artemis master has had a major bump
> (due to major model refactor).
>
> The great news is that the new model is more flexible and lends itself well
> to 5.x features like Virtual Topics as well as being consistent across all
> protocols. The not so good news is that this work required API breakages,
> hence the major version bump.). This refactor work (mostly around the
> addressing scheme [2]) is now completed.
>
> The code base is now in a stable state, and as such, I'd like to start
> thinking about doing a release off of master as an Apache Artemis 2.0.0 to
> get the new changes into the hands of users.
>
> I'd like to open discussion around this topic, does anyone have any
> suggestions, or can think of anything that is needed before we go ahead
> with a major release? This is the perfect time to do anything that could
> break APIs, drop deprecated methods support, break data format etc...
>
> Cheers
> Martyn
>
> [1]
> http://activemq.2283324.n4.nabble.com/DISCUSS-Artemis-addressing-improvements-JMS-component-removal-and-potential-2-0-0-td4719262.html
>
> [2] https://issues.apache.org/jira/browse/ARTEMIS-780
>