Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
@clebertsuconic i have enhanced the tests to check binding ids are the same
(aka not recreated) and also added check for message loss, this is added both
to the redeploy and the
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2187
@jbertram looks good to me. As alot of this is my code, so will wait for
others to review and merge (thinking clebert, martyn, franz here)
---
Github user wy96f commented on the issue:
https://github.com/apache/activemq-artemis/pull/2155
@michaelandrepearce Sorry for the late reply. I rebase the code and tests
pass.
---
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2298
let me run my full CI first, and then I will merge this. just to have an
idea.
---
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2297
---
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
@michaelandrepearce if you don't have time to do it don't worry I will do
it.. I was asking more in a way like.. if you can... know what I mean?
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
Dont merge i need to extend the tests still as per cleberts request
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2298
@jbertram @clebertsuconic here is non-destructive alternative for
routing-type change.
I have added extra bits into the test, where a message is sent before the
change
GitHub user michaelandrepearce opened a pull request:
https://github.com/apache/activemq-artemis/pull/2298
ARTEMIS-2065 Change routing-type isnt destructive.
Revert previous fix
Keep original ConfigChangeTest
Apply new non-destructive fix.
Enhance tests to ensure messages
Github user jbertram commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
LGTM
---
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/2297
ARTEMIS-2072 refactor logic to fix tests
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2072
Alt
Results of the Apache ActiveMQ Artemis 2.6.3 release vote.
Vote passes with 4 Binding Votes, 2 Non Binding Votes
Binding:
Clebert Suconic
Martyn Taylor
Christopher Shannon
Timothy Bish
Non Binding:
Francesco Nigro,
Michael Pearce
Thank you to everyone who contributed and took the time to r
Ok, on that case the I'm sending a result shortly.
On Thu, Sep 6, 2018 at 12:36 PM Justin Bertram wrote:
>
> That's correct, Michael. Additionally, I've found that the current logic
> for updating the addresses & queues causes a catch-22 where the address
> can't be updated until the queue is upd
Sure ill have a pr by tonight hopefully.
Sent from my Samsung Galaxy smartphone.
Original message From: Justin Bertram
Date: 06/09/2018 17:36 (GMT+00:00) To: dev@activemq.apache.org Subject: Re:
[VOTE] Apache ActiveMQ Artemis 2.6.3
That's correct, Michael. Additionally, I'
That's correct, Michael. Additionally, I've found that the current logic
for updating the addresses & queues causes a catch-22 where the address
can't be updated until the queue is updated and vice-versa. Something
fundamentally more clever will be required for this use-case. I'll let you
have a
Ive been looking at the routing type issue. And why the original issue is there.
There isnt actually any issue in the queueUpdate logic that exists already for
routetype.
The issue is before that, where addressinfo update is erroring as trying to
update it route type but the queue hasnt been upd
Clebert the pr you tag here is for a seperate feature.
That particular pr is adding similar updateability for filter but avoids the
very issue here.
Sent from my Samsung Galaxy smartphone.
Original message From: Clebert Suconic
Date: 06/09/2018 16:45 (GMT+00:00) To:
dev@act
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
@clebertsuconic the issue on vote thread is around route-type change from
another JIRA and PR, this is separate feature, though we're avoiding the issue
that introduced, by foll
I will use connectionTTL if no NettyConnectionTimeout is specified.
I don't think we should ever allow a connection to be trying to open
in more than TTL anyways. it should been considered TTL if ping /
pongs were already established.
@Robbie: how that affects the qpid AMQP client? Perhaps we sh
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
@michaelandrepearce as I talked on the vote thread: Can you tweak (or add a
test) that play with a broker restart, and validate the queue is updated on the
journal, and messages not
There's always a thin line between bug and feature. Without trying to
bend the rules, the update you sent on update queues could be
considered a bug fix instead of a feature dev, and we could bring it
into 2.6.x and release 2.6.4 early next week:
https://github.com/apache/activemq-artemis/pull/229
First, we need to agree it's an issue at all! I'm not 100% convinced...
if someone updates the Queue, and set force=true.. it's expected to have issues.
We could update the XML with a big
On Thu, Sep 6, 2018 at 11:32 AM Justin Bertram wrote:
>
> I sent the PR to change the way routing-type up
I sent the PR to change the way routing-type updates were handled which
introduced the issue you're talking about.
That said, it wasn't even possible to update the routing-type on a queue as
noted on the JIRA [1]. Were you testing this behavior previously? If so,
what were the results of that pr
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
@jbertram all squashed now.
---
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
@jbertram yes, i was wondering about squashing and then worried about your
commit, as you dont mind, ill squash.
---
Whats solution for monday? Revert the change? Or someone got an alternative in
pipeline?
Sent from my Samsung Galaxy smartphone.
Original message From: Clebert Suconic
Date: 06/09/2018 14:27 (GMT+00:00) To:
dev@activemq.apache.org Subject: Re: [VOTE] Apache ActiveMQ Artemis
Github user jbertram commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
IMO all these commits should be squashed. I don't mind if you take
authorship of the test I wrote for the other PR (assuming you don't).
---
Github user jbertram commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2296#discussion_r215657277
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java
---
@@ -710,6 +710,7 @@ S
Yes, I think it should use connect timeout by default, though I'd go
with a considerably bigger number than 2 seconds personally.
Robbie
On Wed, 5 Sep 2018 at 23:18, Clebert Suconic wrote:
>
> TL;DR: Should we make use of Netty_CONNECTION_TIMEOUT by default, as
> the connection would block forev
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
if (filter != null && !filter.equals(queue.getFilter())) {
changed = true;
queue.setFilter(filter);
}
if (logger.isDebug
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
@clebertsuconic its updating as per other queue field update see
updateQueue in postoffice.
---
I'd tend to agree with Clebert here I think. Though the outcome is
harsh, it doesnt seem a common enough case to be hit that it warrants
holding the release in itself. It could be documented as known issue
and another release made soon to correct the problem for those that it
actually applies to, w
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2296#discussion_r215631874
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java
---
@@ -710,6 +
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
It is not !!! This will need to be a more complete feature. If you
restart the broker you get the old filter back afaik.
---
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/2296
Is this updating the queue on the journal as well ?
---
Github user jbertram closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2295
---
i don’t think a regression like this qualifies as -1. We can just follow up
with 2.6.4.
>From what I understood you will need to enable force and then update the
XML. You can only do that on purpose and we can document the known issue.
We can have 2.6.4 as early as next Monday.
This release ha
Github user jbertram commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2296#discussion_r215621762
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/api/core/management/ActiveMQServerControl.java
---
@@ -710,6 +710,7 @@ S
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2295
Ive raised a PR https://github.com/apache/activemq-artemis/pull/2296 doing
it via the updateQueue method as other updates are done, so its more inline and
avoids being destructi
Not really. This is a regression and causes message loss as queue is destroyed
when it shouldn't be
Sent from my Samsung Galaxy smartphone.
Original message From: Clebert Suconic
Date: 06/09/2018 12:43 (GMT+00:00) To:
dev@activemq.apache.org Subject: Re: [VOTE] Apache Activ
+1 (non-binding)
Cheers,
Jamie
On Wed, Sep 5, 2018 at 2:02 PM Clebert Suconic
wrote:
>
> +1 for the release
>
>
> +1 to fix the test after the release.
> On Wed, Sep 5, 2018 at 6:25 AM Christopher Shannon
> wrote:
> >
> > My thought are that these tests should be fixed at some point but I don't
It is not a reason to abort the release. We can have a 2.6.4.
The vote had already passed as yesterday night. I didn’t send the result
yesterday as I had a personal errand.
You ok to keep the release if we do a 2.6.4 shortly ?
On Thu, Sep 6, 2018 at 5:49 AM michael.andre.pearce
wrote:
> Im
Seems this change in behaviour is caused by a pr to try fix 2065.
Sent from my Samsung Galaxy smartphone.
Original message From: "michael.andre.pearce"
Date: 06/09/2018 10:48 (GMT+00:00) To:
dev@activemq.apache.org Subject: Re: [VOTE] Apache ActiveMQ Artemis 2.6.3
Im going
Im going to have to -1 this.
It seems that with delete queue force set, if i change routing type by mistake
the queue is destroyed. The intent of this flag was to remove a queue only. Not
be a flag around redeploy on change. As such breaks some existing use.
Unfortunately there was a last minute
Github user xcorail commented on the issue:
https://github.com/apache/activemq-artemis/pull/2290
> I'm dubious about users selecting a project based on the code quality
rating from lgtm.com
Thanks for this feedback. This is something we are trying to assess atm. If
you have r
GitHub user michaelandrepearce opened a pull request:
https://github.com/apache/activemq-artemis/pull/2296
ARTEMIS-2076 Make Filter updateable
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/michaelandrepearce/activemq-artemis 20
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2295
This should just be updated like other values can on the queue via
updateQueue in ActiveMQServer
---
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2295#discussion_r215514830
--- Diff:
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
---
@@ -2718,7 +2715,7 @@
48 matches
Mail list logo
