[GitHub] activemq-artemis issue #1675: ARTEMIS-1526 NullpointerException in ActiveMQS...

[pgfox]

Github user pgfox commented on the issue:

https://github.com/apache/activemq-artemis/pull/1675
  
seems there were changed introduced yesterday -  I will need to pick these 
up retest & push again. 


---

[GitHub] activemq-artemis pull request #1681: ARTEMIS-1531 Adding timedbuffer operati...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1681


---

[GitHub] activemq-artemis pull request #1681: ARTEMIS-1531 Adding timedbuffer operati...

[clebertsuconic]

GitHub user clebertsuconic opened a pull request:

https://github.com/apache/activemq-artemis/pull/1681

ARTEMIS-1531 Adding timedbuffer operations on critical analyzer

Also, making TimedBuffer.stop() synchronized to avoid issues during device 
outages

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-1529

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1681.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1681


commit 0691c8dab1768902882d2dc870b93d7b2eb24f13
Author: Clebert Suconic 
Date:   2017-11-29T20:07:50Z

ARTEMIS-1531 Adding timedbuffer operations on critical analyzer

Also, making TimedBuffer.stop() synchronized to avoid issues during device 
outages




---

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Timothy Bish]

On 11/29/2017 02:23 PM, Clebert Suconic wrote:

On Wed, Nov 29, 2017 at 2:17 PM, Timothy Bish  wrote:

On 11/29/2017 02:13 PM, Clebert Suconic wrote:

This discussion has been open for 15 days. IMO we should move ahead with
whatever is the next step.  Vote probably?


Yes, the PMC needs to vote on something, a discussion thread isn't a vote.
I'd suggest putting together a reasonably detailed proposal of what you see
as the future plan should be and start a vote.



Yes.. I know the vote should be private or public on the dev list
since it is up to the PMC?


Since the discussion is public, I would say dev-list... but wanted to make sure.

There's generally few reasons that something needs to be private, this 
seems like something that is worthy of full community input.


--
Tim Bish
twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Clebert Suconic]

On Wed, Nov 29, 2017 at 2:17 PM, Timothy Bish  wrote:
> On 11/29/2017 02:13 PM, Clebert Suconic wrote:
>>
>> This discussion has been open for 15 days. IMO we should move ahead with
>> whatever is the next step.  Vote probably?
>
>
> Yes, the PMC needs to vote on something, a discussion thread isn't a vote.
> I'd suggest putting together a reasonably detailed proposal of what you see
> as the future plan should be and start a vote.
>


Yes.. I know the vote should be private or public on the dev list
since it is up to the PMC?


Since the discussion is public, I would say dev-list... but wanted to make sure.

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Timothy Bish]

On 11/29/2017 02:13 PM, Clebert Suconic wrote:

This discussion has been open for 15 days. IMO we should move ahead with
whatever is the next step.  Vote probably?


Yes, the PMC needs to vote on something, a discussion thread isn't a 
vote.  I'd suggest putting together a reasonably detailed proposal of 
what you see as the future plan should be and start a vote.




On Wed, Nov 29, 2017 at 2:10 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:


After reading the discussion and thinking about it I think I am on board
with going with ActiveMQ 6.

What's the next step with this?  Do we want to propose a vote or keep the
discussion open longer?

On Thu, Nov 23, 2017 at 3:09 PM, Gary Tully  wrote:


I think ActiveMQ needs a roadmap for sure and I think Artemis is the

future

for a bunch of technical reasons.

Without a clear direction going forward we will loose adoption because I
don't know anyone who likes making a choice.

If you are an existing ActiveMQ user there should be a clear path

forward.

If you are peeking at ActiveMQ for the first time you should find a

vibrant

project.

To avoid confusion, moving forward with ActiveMQ6 looks like the simplest
solution.

That implies migration but also a step migration because there is a new
architecture.

I would propose that the Artemis mainline becomes ActiveMQ 6.x.
Continuing the frequent release cadence of Artemis, any outstanding
migration issues can be promptly catalogued and addressed.

Gary.

On Thu, 23 Nov 2017 at 05:41 Clebert Suconic 
wrote:


The documentation does talk about those things.  Migration guide is

just

a

quick guide on how to migrate but it does not replace the

documentation.

There was some good suggestions you made here as to tools to move
configuration automatically.   But that’s not a requirement to make any
progress. We won’t ever get anuwhere if we aim for perfection as there

will

always be space for more.  Nothing in life is perfect.

Tools and features I think it’s orthogonal to the discussion about the
direction.

On Wed, Nov 22, 2017 at 10:49 PM Tim Bain 

wrote:

On Nov 21, 2017 3:00 PM, "Clebert Suconic" <

clebert.suco...@gmail.com>

wrote:


Another thought - having both brokers long term seems redundant as

there

is

a huge amount of overlap, and I believe the intent (please correct

me

if

this is wrong) is eventually to have Artemis superset all of the

*key*

functionality from AMQ 5.x.

I think all the features are covered at this point. The one exception
is Retroactive Consumers.. however this could be done with browsers
and paging.
It still on my personal list of improvements I want to make. I could
make it happen sooner with some demand.. So I don't think it blocks
anything going forward.

The other feature that has been brought a lot of times.. is virtual
topics.. however with the address model in Artemis.. it's not

needed..

as virtual topic was a way to emulate a queue within a topic, which

is

pretty much what we have on the address model.


In order to facilitate a move, users of AMQ 5.x are going to need a

smooth

transition.  Note that I don't mean to say it has to be seamless,

just

that

it has to be smooth - easy enough to understand and execute.
Let me pose some questions here that may help move this forward:

   - Do we know what it takes to migrates customers from AMQ 5.x to

Artemis?


https://activemq.apache.org/artemis/migration.html

^^ It's in good shape IMO already.


That guide has lots of good information, but it explicitly punts on

the

question of how to migrate a cluster that has existing unconsumed

messages.

Does a migration guide for that subject already exist? If so, let's

link

to

it; if not, I don't think we're ready yet.

There are two possible ways to migrate when messages are

pre-existing:

either you take an outage and convert the messages store somehow, or

you

network the old and new brokers but have clients use only the new

broker,

and you configure the brokers so that all of the messages flow from

the

old

broker to the new one without downtime. Note that the second approach

won't

migrate scheduled messages, so it might be necessary to use a hybrid
approach depending on the use case. Are Artemis and ActiveMQ capable

of

being networked together to allow the second approach? I've always

assumed

that it could be done since Artemis supports OpenWire, but I've never

heard

anyone say it was possible. I think we'd want the migration guide to

talk a

bit about options for how to perform the actual operational

migration,

not

just how to configure Artemis to make it behave similarly to ActiveMQ

or

HornetQ (though that's important too, and the guide does that well).

Also,

the guide should talk about what happens if a user wants to migrate

when

their broker contains more messages than will fit into Artemis's

memory,

since it's possible that some users might 

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Clebert Suconic]

This discussion has been open for 15 days. IMO we should move ahead with
whatever is the next step.  Vote probably?

On Wed, Nov 29, 2017 at 2:10 PM Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:

> After reading the discussion and thinking about it I think I am on board
> with going with ActiveMQ 6.
>
> What's the next step with this?  Do we want to propose a vote or keep the
> discussion open longer?
>
> On Thu, Nov 23, 2017 at 3:09 PM, Gary Tully  wrote:
>
> > I think ActiveMQ needs a roadmap for sure and I think Artemis is the
> future
> > for a bunch of technical reasons.
> >
> > Without a clear direction going forward we will loose adoption because I
> > don't know anyone who likes making a choice.
> >
> > If you are an existing ActiveMQ user there should be a clear path
> forward.
> > If you are peeking at ActiveMQ for the first time you should find a
> vibrant
> > project.
> >
> > To avoid confusion, moving forward with ActiveMQ6 looks like the simplest
> > solution.
> >
> > That implies migration but also a step migration because there is a new
> > architecture.
> >
> > I would propose that the Artemis mainline becomes ActiveMQ 6.x.
> > Continuing the frequent release cadence of Artemis, any outstanding
> > migration issues can be promptly catalogued and addressed.
> >
> > Gary.
> >
> > On Thu, 23 Nov 2017 at 05:41 Clebert Suconic 
> > wrote:
> >
> > > The documentation does talk about those things.  Migration guide is
> just
> > a
> > > quick guide on how to migrate but it does not replace the
> documentation.
> > >
> > > There was some good suggestions you made here as to tools to move
> > > configuration automatically.   But that’s not a requirement to make any
> > > progress. We won’t ever get anuwhere if we aim for perfection as there
> > will
> > > always be space for more.  Nothing in life is perfect.
> > >
> > > Tools and features I think it’s orthogonal to the discussion about the
> > > direction.
> > >
> > > On Wed, Nov 22, 2017 at 10:49 PM Tim Bain 
> wrote:
> > >
> > > > On Nov 21, 2017 3:00 PM, "Clebert Suconic" <
> clebert.suco...@gmail.com>
> > > > wrote:
> > > >
> > > > > Another thought - having both brokers long term seems redundant as
> > > there
> > > > is
> > > > > a huge amount of overlap, and I believe the intent (please correct
> me
> > > if
> > > > > this is wrong) is eventually to have Artemis superset all of the
> > *key*
> > > > > functionality from AMQ 5.x.
> > > >
> > > > I think all the features are covered at this point. The one exception
> > > > is Retroactive Consumers.. however this could be done with browsers
> > > > and paging.
> > > > It still on my personal list of improvements I want to make. I could
> > > > make it happen sooner with some demand.. So I don't think it blocks
> > > > anything going forward.
> > > >
> > > > The other feature that has been brought a lot of times.. is virtual
> > > > topics.. however with the address model in Artemis.. it's not
> needed..
> > > > as virtual topic was a way to emulate a queue within a topic, which
> is
> > > > pretty much what we have on the address model.
> > > >
> > > > >
> > > > > In order to facilitate a move, users of AMQ 5.x are going to need a
> > > > smooth
> > > > > transition.  Note that I don't mean to say it has to be seamless,
> > just
> > > > that
> > > > > it has to be smooth - easy enough to understand and execute.
> > > >
> > > > >
> > > > > Let me pose some questions here that may help move this forward:
> > > > >
> > > > >   - Do we know what it takes to migrates customers from AMQ 5.x to
> > > > Artemis?
> > > >
> > > >
> > > > https://activemq.apache.org/artemis/migration.html
> > > >
> > > > ^^ It's in good shape IMO already.
> > > >
> > > >
> > > > That guide has lots of good information, but it explicitly punts on
> the
> > > > question of how to migrate a cluster that has existing unconsumed
> > > messages.
> > > > Does a migration guide for that subject already exist? If so, let's
> > link
> > > to
> > > > it; if not, I don't think we're ready yet.
> > > >
> > > > There are two possible ways to migrate when messages are
> pre-existing:
> > > > either you take an outage and convert the messages store somehow, or
> > you
> > > > network the old and new brokers but have clients use only the new
> > broker,
> > > > and you configure the brokers so that all of the messages flow from
> the
> > > old
> > > > broker to the new one without downtime. Note that the second approach
> > > won't
> > > > migrate scheduled messages, so it might be necessary to use a hybrid
> > > > approach depending on the use case. Are Artemis and ActiveMQ capable
> of
> > > > being networked together to allow the second approach? I've always
> > > assumed
> > > > that it could be done since Artemis supports OpenWire, but I've never
> > > heard
> > > > anyone say it was possible. I think we'd want the migration guide to
> > > talk a

Re: [DISCUSS] Confusion surrounding the ActiveMQ project roadmap

[Christopher Shannon]

After reading the discussion and thinking about it I think I am on board
with going with ActiveMQ 6.

What's the next step with this?  Do we want to propose a vote or keep the
discussion open longer?

On Thu, Nov 23, 2017 at 3:09 PM, Gary Tully  wrote:

> I think ActiveMQ needs a roadmap for sure and I think Artemis is the future
> for a bunch of technical reasons.
>
> Without a clear direction going forward we will loose adoption because I
> don't know anyone who likes making a choice.
>
> If you are an existing ActiveMQ user there should be a clear path forward.
> If you are peeking at ActiveMQ for the first time you should find a vibrant
> project.
>
> To avoid confusion, moving forward with ActiveMQ6 looks like the simplest
> solution.
>
> That implies migration but also a step migration because there is a new
> architecture.
>
> I would propose that the Artemis mainline becomes ActiveMQ 6.x.
> Continuing the frequent release cadence of Artemis, any outstanding
> migration issues can be promptly catalogued and addressed.
>
> Gary.
>
> On Thu, 23 Nov 2017 at 05:41 Clebert Suconic 
> wrote:
>
> > The documentation does talk about those things.  Migration guide is just
> a
> > quick guide on how to migrate but it does not replace the documentation.
> >
> > There was some good suggestions you made here as to tools to move
> > configuration automatically.   But that’s not a requirement to make any
> > progress. We won’t ever get anuwhere if we aim for perfection as there
> will
> > always be space for more.  Nothing in life is perfect.
> >
> > Tools and features I think it’s orthogonal to the discussion about the
> > direction.
> >
> > On Wed, Nov 22, 2017 at 10:49 PM Tim Bain  wrote:
> >
> > > On Nov 21, 2017 3:00 PM, "Clebert Suconic" 
> > > wrote:
> > >
> > > > Another thought - having both brokers long term seems redundant as
> > there
> > > is
> > > > a huge amount of overlap, and I believe the intent (please correct me
> > if
> > > > this is wrong) is eventually to have Artemis superset all of the
> *key*
> > > > functionality from AMQ 5.x.
> > >
> > > I think all the features are covered at this point. The one exception
> > > is Retroactive Consumers.. however this could be done with browsers
> > > and paging.
> > > It still on my personal list of improvements I want to make. I could
> > > make it happen sooner with some demand.. So I don't think it blocks
> > > anything going forward.
> > >
> > > The other feature that has been brought a lot of times.. is virtual
> > > topics.. however with the address model in Artemis.. it's not needed..
> > > as virtual topic was a way to emulate a queue within a topic, which is
> > > pretty much what we have on the address model.
> > >
> > > >
> > > > In order to facilitate a move, users of AMQ 5.x are going to need a
> > > smooth
> > > > transition.  Note that I don't mean to say it has to be seamless,
> just
> > > that
> > > > it has to be smooth - easy enough to understand and execute.
> > >
> > > >
> > > > Let me pose some questions here that may help move this forward:
> > > >
> > > >   - Do we know what it takes to migrates customers from AMQ 5.x to
> > > Artemis?
> > >
> > >
> > > https://activemq.apache.org/artemis/migration.html
> > >
> > > ^^ It's in good shape IMO already.
> > >
> > >
> > > That guide has lots of good information, but it explicitly punts on the
> > > question of how to migrate a cluster that has existing unconsumed
> > messages.
> > > Does a migration guide for that subject already exist? If so, let's
> link
> > to
> > > it; if not, I don't think we're ready yet.
> > >
> > > There are two possible ways to migrate when messages are pre-existing:
> > > either you take an outage and convert the messages store somehow, or
> you
> > > network the old and new brokers but have clients use only the new
> broker,
> > > and you configure the brokers so that all of the messages flow from the
> > old
> > > broker to the new one without downtime. Note that the second approach
> > won't
> > > migrate scheduled messages, so it might be necessary to use a hybrid
> > > approach depending on the use case. Are Artemis and ActiveMQ capable of
> > > being networked together to allow the second approach? I've always
> > assumed
> > > that it could be done since Artemis supports OpenWire, but I've never
> > heard
> > > anyone say it was possible. I think we'd want the migration guide to
> > talk a
> > > bit about options for how to perform the actual operational migration,
> > not
> > > just how to configure Artemis to make it behave similarly to ActiveMQ
> or
> > > HornetQ (though that's important too, and the guide does that well).
> > Also,
> > > the guide should talk about what happens if a user wants to migrate
> when
> > > their broker contains more messages than will fit into Artemis's
> memory,
> > > since it's possible that some users might be in that 

[GitHub] activemq-artemis pull request #1678: ARTEMIS-1529 Fixing Ref count over asyn...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1678


---

[GitHub] activemq-artemis issue #1678: ARTEMIS-1529 Fixing Ref count over asynchronou...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1678
  
it's fine now.. false alarm


---

[GitHub] activemq-artemis issue #1678: ARTEMIS-1529 Fixing Ref count over asynchronou...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1678
  
please, do not merge this yet


---

[GitHub] activemq-artemis issue #1678: ARTEMIS-1529 Fixing Ref count over asynchronou...

[clebertsuconic]

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1678
  
with this fix, yes


---

[GitHub] activemq-artemis pull request #1680: ARTEMIS-1530 Fix expiry statistics

[stanlyDoge]

GitHub user stanlyDoge opened a pull request:

https://github.com/apache/activemq-artemis/pull/1680

ARTEMIS-1530 Fix expiry statistics



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stanlyDoge/activemq-artemis-1 ENTMQBR-919

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1680.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1680


commit fd097a50863964f0e68fab6ef40c97da6cbd756e
Author: Stanislav Knot 
Date:   2017-11-29T09:56:42Z

ARTEMIS-1530 Fix expiry statistics




---

[GitHub] activemq-artemis issue #1679: ARTEMIS-1523 Allow MQTT with dynamic cluster

[Skiler]

Github user Skiler commented on the issue:

https://github.com/apache/activemq-artemis/pull/1679
  
Hi @jbertram 

I created a new pull request, I hope it has the needed organization.

Thanks in advance


---

[GitHub] activemq-artemis pull request #1677: Allow mqtt with dynamic cluster

[Skiler]

Github user Skiler closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1677


---

[GitHub] activemq-artemis pull request #1679: ARTEMIS-1523 Allow MQTT with dynamic cl...

[Skiler]

GitHub user Skiler opened a pull request:

https://github.com/apache/activemq-artemis/pull/1679

ARTEMIS-1523 Allow MQTT with dynamic cluster



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Skiler/activemq-artemis securebranch

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1679.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1679


commit 1ea3fd90178132d1d23827c01b05df5e153cd141
Author: raul.valdoleiros 
Date:   2017-11-24T17:53:14Z

ARTEMIS-1523 Allow MQTT with dynamic cluster




---

[GitHub] activemq-artemis issue #1628: ARTEMIS-1364: Enable internal sorting in Hawti...

[mtaylor]

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1628
  
Nice work @RaiSaurabh.  Thanks a lot


---

[GitHub] activemq-artemis pull request #1628: ARTEMIS-1364: Enable internal sorting i...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1628


---

[GitHub] activemq-artemis issue #1676: [ARTEMIS-1527] - [Artemis Testsuite] ActiveMQM...

[JiriOndrusek]

Github user JiriOndrusek commented on the issue:

https://github.com/apache/activemq-artemis/pull/1676
  
Thank you for your responses.

@clebertsuconic you are right, with this change FailoverTest is failing

I'll try to find solution for FailoverTest to succeed.
(it will take me some time to debug and understand it)

@clebertsuconic @mtaylor I'm opened to any suggestions, as there are a lot 
of aspects, about which I don't know/understand. 


---

[GitHub] activemq-artemis issue #1678: ARTEMIS-1529 Fixing Ref count over asynchronou...

[kornys]

Github user kornys commented on the issue:

https://github.com/apache/activemq-artemis/pull/1678
  
@clebertsuconic dothese tests pass with current fixes?


---

[GitHub] activemq-artemis issue #1676: [ARTEMIS-1527] - [Artemis Testsuite] ActiveMQM...

[mtaylor]

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1676
  
@clebertsuconic The problem here is that any thread that blocks 
indefinitely takes up resources in the Thread pool.  If you have several 
threads trying reconnect, the ThreadPool may be exhausted and can not be used 
to perform any other tasks.  My opinion here is that no task we add to the 
ThreadPool should block indefinitely, for retry here we should attempt to 
connect, if it fails schedule another attempt connect call, and give up the 
thread.  Jiri's made a start on that, but we may need to flesh out some of the 
details.  There's a similar problem with LargeMessage receive().


---