[jira] [Commented] (ARTEMIS-2110) JDBC LeaseLocker repeated renew or renew after aquire can fail in error
[ https://issues.apache.org/jira/browse/ARTEMIS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641690#comment-16641690 ] ASF GitHub Bot commented on ARTEMIS-2110: - GitHub user gtully reopened a pull request: https://github.com/apache/activemq-artemis/pull/2346 ARTEMIS-2110 allow a lease renew without update to the expiry timesta… …mp. Fix intermittent failure of org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock You can merge this pull request into a Git repository by running: $ git pull https://github.com/gtully/activemq-artemis ARTEMIS-2110 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2346.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 #2346 commit 2e96d9b5ccc8fdbf0081ebb0df8c6a4a81663d34 Author: gtully Date: 2018-10-05T11:10:56Z ARTEMIS-1684 - don't build the -web module due to the node and gitbook dependency for travis ci commit 0963c3fd6bda6f8295c3aeeb15764fa99c6d5822 Author: gtully Date: 2018-10-04T15:47:16Z ARTEMIS-2110 allow a lease renew without update to the expiry timestamp. Fix intermittent failure of org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock > JDBC LeaseLocker repeated renew or renew after aquire can fail in error > --- > > Key: ARTEMIS-2110 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2110 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 2.7.0 > > > There is an intermittent failure in: > org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock > (seems to block pr ci, and reproduced for me 20% of the time) > if the db currentTime has not moved on, using the same lease time results in > a failure. A renew immediately after acquiring the lock is a sensible pattern > to verify the aquire. > > The lock renew needs >= in place or > on the WHERE clause to allow an > 'identity' lease to succeed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2110) JDBC LeaseLocker repeated renew or renew after aquire can fail in error
[ https://issues.apache.org/jira/browse/ARTEMIS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641689#comment-16641689 ] ASF GitHub Bot commented on ARTEMIS-2110: - Github user gtully closed the pull request at: https://github.com/apache/activemq-artemis/pull/2346 > JDBC LeaseLocker repeated renew or renew after aquire can fail in error > --- > > Key: ARTEMIS-2110 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2110 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 2.7.0 > > > There is an intermittent failure in: > org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock > (seems to block pr ci, and reproduced for me 20% of the time) > if the db currentTime has not moved on, using the same lease time results in > a failure. A renew immediately after acquiring the lock is a sensible pattern > to verify the aquire. > > The lock renew needs >= in place or > on the WHERE clause to allow an > 'identity' lease to succeed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7068) Advisory messages are empty when received with a AMQP subscription
[ https://issues.apache.org/jira/browse/AMQ-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-7068: -- Issue Type: New Feature (was: Bug) > Advisory messages are empty when received with a AMQP subscription > -- > > Key: AMQ-7068 > URL: https://issues.apache.org/jira/browse/AMQ-7068 > Project: ActiveMQ > Issue Type: New Feature > Components: AMQP, Transport >Affects Versions: 5.15.6 > Environment: ActiveMQ 5.15.6, JDK 1.8.0_161, Windows 10, AMQPNetLite > 2.1.4 >Reporter: Johannes Baeurle >Priority: Major > Attachments: issueamq.PNG, issueamq2.PNG, issueamq3.PNG > > > We are currently moving from OpenWire to AMQP with .NET Library amqpnetlite > ([https://github.com/Azure/amqpnetlite)] to communicate. So far most things > work fine, but we actively used and need the advisory messages in order to > recognize if other clients disconnect for example. > Accessing the advisory messages through the topic is not the problem, but the > body is null for the ActiveMQ.Advisory.Connection topic. There are some > properties set, but no body set and I'm not able to find any important > information, like the RemoveInfo. I attached a few screenshots from debugger. > To be honest, I don't know if this is the desired behavior, but I think if > there are messages on the advisory topic they should be useful. > I know that a byte representation wouldn't be that useful, but you could > present the information in json or xml format, like in Stomp? > (https://issues.apache.org/jira/browse/AMQ-2098) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7068) Advisory messages are empty when received with a AMQP subscription
[ https://issues.apache.org/jira/browse/AMQ-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-7068: -- Priority: Minor (was: Major) > Advisory messages are empty when received with a AMQP subscription > -- > > Key: AMQ-7068 > URL: https://issues.apache.org/jira/browse/AMQ-7068 > Project: ActiveMQ > Issue Type: New Feature > Components: AMQP, Transport >Affects Versions: 5.15.6 > Environment: ActiveMQ 5.15.6, JDK 1.8.0_161, Windows 10, AMQPNetLite > 2.1.4 >Reporter: Johannes Baeurle >Priority: Minor > Attachments: issueamq.PNG, issueamq2.PNG, issueamq3.PNG > > > We are currently moving from OpenWire to AMQP with .NET Library amqpnetlite > ([https://github.com/Azure/amqpnetlite)] to communicate. So far most things > work fine, but we actively used and need the advisory messages in order to > recognize if other clients disconnect for example. > Accessing the advisory messages through the topic is not the problem, but the > body is null for the ActiveMQ.Advisory.Connection topic. There are some > properties set, but no body set and I'm not able to find any important > information, like the RemoveInfo. I attached a few screenshots from debugger. > To be honest, I don't know if this is the desired behavior, but I think if > there are messages on the advisory topic they should be useful. > I know that a byte representation wouldn't be that useful, but you could > present the information in json or xml format, like in Stomp? > (https://issues.apache.org/jira/browse/AMQ-2098) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7068) Advisory messages are empty when received with a AMQP subscription
[ https://issues.apache.org/jira/browse/AMQ-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641728#comment-16641728 ] Timothy Bish commented on AMQ-7068: --- Representing the OpenWire protocol objects in the AMQP body requires some work to produce conversions of the data into some types that can be marshalled in the AMQP protocol's type system. Currently no proper mapping has been done but if you want to contribute it we'd be happy to accept the patches. You'd likely need to convert the types into Map representations for the broadest comparability, XML would work but would be harder for folks to deal with than a simple mapping. > Advisory messages are empty when received with a AMQP subscription > -- > > Key: AMQ-7068 > URL: https://issues.apache.org/jira/browse/AMQ-7068 > Project: ActiveMQ > Issue Type: New Feature > Components: AMQP, Transport >Affects Versions: 5.15.6 > Environment: ActiveMQ 5.15.6, JDK 1.8.0_161, Windows 10, AMQPNetLite > 2.1.4 >Reporter: Johannes Baeurle >Priority: Minor > Attachments: issueamq.PNG, issueamq2.PNG, issueamq3.PNG > > > We are currently moving from OpenWire to AMQP with .NET Library amqpnetlite > ([https://github.com/Azure/amqpnetlite)] to communicate. So far most things > work fine, but we actively used and need the advisory messages in order to > recognize if other clients disconnect for example. > Accessing the advisory messages through the topic is not the problem, but the > body is null for the ActiveMQ.Advisory.Connection topic. There are some > properties set, but no body set and I'm not able to find any important > information, like the RemoveInfo. I attached a few screenshots from debugger. > To be honest, I don't know if this is the desired behavior, but I think if > there are messages on the advisory topic they should be useful. > I know that a byte representation wouldn't be that useful, but you could > present the information in json or xml format, like in Stomp? > (https://issues.apache.org/jira/browse/AMQ-2098) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers
[
https://issues.apache.org/jira/browse/ARTEMIS-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641741#comment-16641741
]
ASF GitHub Bot commented on ARTEMIS-2103:
-
Github user gtully closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2341
> VirtualTopic doesn't work correctly with multiple consumers
> ---
>
> Key: ARTEMIS-2103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2103
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Affects Versions: 2.6.3
>Reporter: Pawel
>Assignee: Gary Tully
>Priority: Major
>
> It's impossibe to subscribe multiple virtual topics with the same consumer
> name.
> I've configured acceptor like described in documentation:
> {code:java}
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2{code}
> When I'm connecting first consumer:
> *Consumer.cons1.VirtualTopic.t1*
> proper binding is created.
> Next I'm trying to connect second consumer with the same name:
> *Consumer.cons1.VirtualTopic.t2*
> But no binding is created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers
[
https://issues.apache.org/jira/browse/ARTEMIS-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641742#comment-16641742
]
ASF GitHub Bot commented on ARTEMIS-2103:
-
GitHub user gtully reopened a pull request:
https://github.com/apache/activemq-artemis/pull/2341
ARTEMIS-2103 - use the full openwire consumer queue for the mapped vi…
…rtual topic queue binding, fix and test
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gtully/activemq-artemis ARTEMIS-2103
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2341.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 #2341
commit 6281101971bdbc32f8932738b59f01cf3adfbd0d
Author: gtully
Date: 2018-10-03T12:24:42Z
ARTEMIS-2103 - use the full openwire consumer queue for the mapped virtual
topic queue binding, fix and test
> VirtualTopic doesn't work correctly with multiple consumers
> ---
>
> Key: ARTEMIS-2103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2103
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Affects Versions: 2.6.3
>Reporter: Pawel
>Assignee: Gary Tully
>Priority: Major
>
> It's impossibe to subscribe multiple virtual topics with the same consumer
> name.
> I've configured acceptor like described in documentation:
> {code:java}
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2{code}
> When I'm connecting first consumer:
> *Consumer.cons1.VirtualTopic.t1*
> proper binding is created.
> Next I'm trying to connect second consumer with the same name:
> *Consumer.cons1.VirtualTopic.t2*
> But no binding is created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different pagefiles.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641757#comment-16641757
]
Gary Tully commented on AMQ-7067:
-
[~jgoodyear] I think the patch is on the right track but I think it needs some
small mod.
The ack message file map can do what we need but I think it has to track the
association between the prepare record location and the outcome
(commit/rollback) location rather than the actual message or ack commands.
ie: all of the transaction commands could be in one data file, the prepare in
another and the outcome in a third. Tracking the link between the third and the
first is not sufficient in this case. It should be possible to validate that
with another test scenario.
I think the prepare record location needs to be tracked in the in memory tx
representation in some way to make it available to the outcome processor.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> ---
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully updated AMQ-7067:
Summary: KahaDB Recovery can experience a dangling transaction when prepare
and commit occur on different data files. (was: KahaDB Recovery can experience
a dangling transaction when prepare and commit occur on different pagefiles.)
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-2114) hawtio destination delete and purge buttons overlap when pane is resized
Francesco Nigro created ARTEMIS-2114: Summary: hawtio destination delete and purge buttons overlap when pane is resized Key: ARTEMIS-2114 URL: https://issues.apache.org/jira/browse/ARTEMIS-2114 Project: ActiveMQ Artemis Issue Type: Bug Components: Web Console Affects Versions: 2.6.3 Reporter: Francesco Nigro Assignee: Francesco Nigro Fix For: 2.7.0, 2.6.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2114) hawtio destination delete and purge buttons overlap when pane is resized
[ https://issues.apache.org/jira/browse/ARTEMIS-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro updated ARTEMIS-2114: - Description: When deleting or purging a queue with a long name in Hawtio, if the left pane is resized by dragging the divider to the right, the delete and purge buttons overlap and do not move to separate grid rows as they do when the entire browser window is resized. > hawtio destination delete and purge buttons overlap when pane is resized > > > Key: ARTEMIS-2114 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2114 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > When deleting or purging a queue with a long name in Hawtio, if the left pane > is resized by dragging the divider to the right, the delete and purge buttons > overlap and do not move to separate grid rows as they do when the entire > browser window is resized. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2114) hawtio destination delete and purge buttons overlap when pane is resized
[ https://issues.apache.org/jira/browse/ARTEMIS-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16641905#comment-16641905 ] ASF GitHub Bot commented on ARTEMIS-2114: - GitHub user franz1981 opened a pull request: https://github.com/apache/activemq-artemis/pull/2349 ARTEMIS-2114 hawtio dest delete/purge buttons overlap if pane resized Changing the view layout from horizontal to vertical avoid the resizing issue You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-2114 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2349.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 #2349 commit d603332a8f23b86bf08bf3992c9e584bf9a212b7 Author: Francesco Nigro Date: 2018-10-08T13:54:12Z ARTEMIS-2114 hawtio dest delete/purge buttons overlap if pane resized Changing the view layout from horizontal to vertical avoid the resizing issue > hawtio destination delete and purge buttons overlap when pane is resized > > > Key: ARTEMIS-2114 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2114 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > When deleting or purging a queue with a long name in Hawtio, if the left pane > is resized by dragging the divider to the right, the delete and purge buttons > overlap and do not move to separate grid rows as they do when the entire > browser window is resized. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642067#comment-16642067
]
Jamie goodyear commented on AMQ-7067:
-
Hi Gary,
The crux of this patch is to prevent the GC of the PageFile such that on
recovery Commit/Rollback can be processed as per existing logic. No changes
to the existing processors is required.
Please note, the problem was happening with Non-XA transactions as well, hence
the addition of non-xa unit tests. The commit/rollback would get lost via GC,
by updating the code to mark those index to not be GC'd the behavoir is fixed
for both XA and Non-XA transactions. Adding in a new structure and logic to
track the TX lifeCycle would not touch the Non-XA transaction case.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642107#comment-16642107
]
Gary Tully commented on AMQ-7067:
-
In the xa case, I don't think the prepare record location is tracked, so it can
get lost, leaving messages and a commit/rollback - which will barf. I am
suggesting tracking the outcome record with the prepare location, and possibly
with all of the updates.
I had not considered the non xa case, in that case, the commit is all that is
needed b/c the default will be to rollback. The commit outcome location needs
to be linked to each of the add commands in turn.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642107#comment-16642107
]
Gary Tully edited comment on AMQ-7067 at 10/8/18 4:36 PM:
--
In the xa case, I don't think the prepare record location is tracked, so it can
get lost, leaving messages and a commit/rollback - which will barf. I am
suggesting tracking the outcome record with the prepare location, and possibly
with all of the updates.
I had not considered the non xa case, in that case, the commit is all that is
needed b/c the default will be to rollback. The commit outcome location needs
to be linked to each of the update commands in turn.
was (Author: gtully):
In the xa case, I don't think the prepare record location is tracked, so it can
get lost, leaving messages and a commit/rollback - which will barf. I am
suggesting tracking the outcome record with the prepare location, and possibly
with all of the updates.
I had not considered the non xa case, in that case, the commit is all that is
needed b/c the default will be to rollback. The commit outcome location needs
to be linked to each of the add commands in turn.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642107#comment-16642107
]
Gary Tully edited comment on AMQ-7067 at 10/8/18 4:37 PM:
--
In the xa case, I don't think the prepare record location is tracked, so it can
get lost, leaving updates and a commit/rollback - which will barf. I am
suggesting tracking the outcome record with the prepare location, and possibly
with all of the updates.
I had not considered the non xa case, in that case, the commit is all that is
needed b/c the default will be to rollback. The commit outcome location needs
to be linked to each of the update commands in turn.
was (Author: gtully):
In the xa case, I don't think the prepare record location is tracked, so it can
get lost, leaving messages and a commit/rollback - which will barf. I am
suggesting tracking the outcome record with the prepare location, and possibly
with all of the updates.
I had not considered the non xa case, in that case, the commit is all that is
needed b/c the default will be to rollback. The commit outcome location needs
to be linked to each of the update commands in turn.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642151#comment-16642151
]
Gary Tully commented on AMQ-7067:
-
I see that losing a prepare record after an outcome is still recoverable, once
all of the updates are present.
However I think that a prepare record needs to be tracked in case if falls
outside of the current txRange or current write file.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642151#comment-16642151
]
Gary Tully edited comment on AMQ-7067 at 10/8/18 5:07 PM:
--
I see that losing a prepare record after an outcome is still recoverable, once
all of the updates are present.
However I think that a prepare record needs to be tracked in case it falls
outside of the current txRange or current write file.
was (Author: gtully):
I see that losing a prepare record after an outcome is still recoverable, once
all of the updates are present.
However I think that a prepare record needs to be tracked in case if falls
outside of the current txRange or current write file.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642382#comment-16642382 ] ASF GitHub Bot commented on ARTEMIS-2094: - GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/2351 Revert "ARTEMIS-2094 - Fix Configuration change loss when network Issue" This reverts commit cce0e1927c258ce6f3c3c3cb0d90bad5337b7d12. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis master_work Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2351.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 #2351 commit 6015e24b5edf53d48c107e86bb94652327cb43a8 Author: Justin Bertram Date: 2018-10-01T21:15:36Z Revert "ARTEMIS-2094 - Fix Configuration change loss when network Issue" This reverts commit cce0e1927c258ce6f3c3c3cb0d90bad5337b7d12. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642389#comment-16642389 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/2351 The commit for ARTEMIS-2094 needs to be reverted because (as noted on the JIRA 10 days ago) it is breaking lots of tests. For example, all the tests in `org.apache.activemq.artemis.tests.integration.cluster.failover.SecurityFailoverTest` are currently failing. @michaelandrepearce, I'm fine if you want to send a PR to fix the problems with the original commit so that this one doesn't have to be merged. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642578#comment-16642578 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2351 @jbertram is there an easy place to see all fails? reason i ask as i know we dont have apache build that does the entire suite which can take several hours and i assume you have a list to hand FYI SecurityFailoverTest is a quick fix because its actually re-setting up the roles manually during failover deep within security hierarchy, but not updating the actual server config. But i want to ensure i fix all before i send a PR. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642593#comment-16642593
]
Jamie goodyear commented on AMQ-7067:
-
I've updated the PR after our discussion on IRC.
All locations are updated on commit/rollback/prepare.
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different pagefiles.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new pagefile to be
> created.
> Commit the XA transaction. Commit will land on the new page file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress tx
> {color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};
> {color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642601#comment-16642601 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user jbertram commented on the issue: https://github.com/apache/activemq-artemis/pull/2351 @michaelandrepearce, unfortunately the build I have access to no longer has the history as too many builds have been run since then. Push your changes to your GitHub repo and tell me the branch name and I'll run the build again and provide relevant results. It will take a little time, but should be relatively painless. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2114) hawtio destination delete and purge buttons overlap when pane is resized
[ https://issues.apache.org/jira/browse/ARTEMIS-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642652#comment-16642652 ] ASF GitHub Bot commented on ARTEMIS-2114: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2349 > hawtio destination delete and purge buttons overlap when pane is resized > > > Key: ARTEMIS-2114 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2114 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Web Console >Affects Versions: 2.6.3 >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > When deleting or purging a queue with a long name in Hawtio, if the left pane > is resized by dragging the divider to the right, the delete and purge buttons > overlap and do not move to separate grid rows as they do when the entire > browser window is resized. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642666#comment-16642666 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2351 I could pass the tests with a partial revert: https://github.com/clebertsuconic/activemq-artemis/commit/d41d22a51b3e42ca771bfba5ad21267a90427bb2 However one of your tests in RedeployTest is failing. I'm confused on how to accomodate this. I will look more tomorrow during my day. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642669#comment-16642669 ] ASF GitHub Bot commented on ARTEMIS-2094: - GitHub user michaelandrepearce opened a pull request: https://github.com/apache/activemq-artemis/pull/2354 ARTEMIS-2094 Capture SecurityRepository changes to server config This fixes SecurityFailoverTest and any other test that only updates security repository and not the config. You can merge this pull request into a Git repository by running: $ git pull https://github.com/michaelandrepearce/activemq-artemis ARTEMIS-2094-enhancement Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2354.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 #2354 commit 9d76d0588dd7d4eb12e1191368e1ca725da95b2d Author: Michael André Pearce Date: 2018-10-08T23:35:52Z ARTEMIS-2094 Capture SecurityRepository changes to server config This fixes SecurityFailoverTest and any other test that only updates security repository and not the config. > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642670#comment-16642670 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2351 @jbertram if you could check this one https://github.com/apache/activemq-artemis/pull/2354 > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7068) Advisory messages are empty when received with a AMQP subscription
[ https://issues.apache.org/jira/browse/AMQ-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16642839#comment-16642839 ] Johannes Baeurle commented on AMQ-7068: --- Wow, thanks for the quick answer and for correcting the issue! I'd be happy if I can contribute, as we would be very happy about that feature. I've seen there is a activemq mirror on github, do you also accept pull requests there or just patches in here? > Advisory messages are empty when received with a AMQP subscription > -- > > Key: AMQ-7068 > URL: https://issues.apache.org/jira/browse/AMQ-7068 > Project: ActiveMQ > Issue Type: New Feature > Components: AMQP, Transport >Affects Versions: 5.15.6 > Environment: ActiveMQ 5.15.6, JDK 1.8.0_161, Windows 10, AMQPNetLite > 2.1.4 >Reporter: Johannes Baeurle >Priority: Minor > Attachments: issueamq.PNG, issueamq2.PNG, issueamq3.PNG > > > We are currently moving from OpenWire to AMQP with .NET Library amqpnetlite > ([https://github.com/Azure/amqpnetlite)] to communicate. So far most things > work fine, but we actively used and need the advisory messages in order to > recognize if other clients disconnect for example. > Accessing the advisory messages through the topic is not the problem, but the > body is null for the ActiveMQ.Advisory.Connection topic. There are some > properties set, but no body set and I'm not able to find any important > information, like the RemoveInfo. I attached a few screenshots from debugger. > To be honest, I don't know if this is the desired behavior, but I think if > there are messages on the advisory topic they should be useful. > I know that a byte representation wouldn't be that useful, but you could > present the information in json or xml format, like in Stomp? > (https://issues.apache.org/jira/browse/AMQ-2098) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
