[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922811=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922811 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 10/Jun/24 12:50 Start Date: 10/Jun/24 12:50 Worklog Time Spent: 10m Work Description: gtully commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2158260584 > @gtully Do you know of any current test that demonstrates (or at least includes) having to wait for a lease expiry for the JDBC case? https://github.com/apache/activemq-artemis/blob/362dbd11ac132e66f7bce99eb0fb4aa020346210/artemis-server/src/test/java/org/apache/activemq/artemis/core/server/impl/jdbc/JdbcLeaseLockTest.java#L218 that looks like it should have to wait. Issue Time Tracking --- Worklog Id: (was: 922811) Time Spent: 1h (was: 50m) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922794=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922794 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 10/Jun/24 11:51 Start Date: 10/Jun/24 11:51 Worklog Time Spent: 10m Work Description: AntonRoskvist commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2158137960 @gtully Do you know of any current test that demonstrates (or at least includes) having to wait for a lease expiry for the JDBC case? Issue Time Tracking --- Worklog Id: (was: 922794) Time Spent: 50m (was: 40m) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922641=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922641 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 07/Jun/24 19:35 Start Date: 07/Jun/24 19:35 Worklog Time Spent: 10m Work Description: AntonRoskvist commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2155417744 Thanks for your feedback @gtully If I am not mistaken the first case should be addressed already, where the coordination-id takes precedence over the configured nodeID. It should be verified by: `org.apache.activemq.artemis.tests.integration.replication.LockManagerReplicationTest#testPrimaryPeers()` let me know if I misunderstood though. I will take a look at the JDBC case, thanks! Issue Time Tracking --- Worklog Id: (was: 922641) Time Spent: 40m (was: 0.5h) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922149=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922149 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 05/Jun/24 11:24 Start Date: 05/Jun/24 11:24 Worklog Time Spent: 10m Work Description: gtully commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2149588357 Another use case is jdbc, it currently uses a new uuid as the node id, it too could benefit from a shared identity, allowing a restart/reconnect of an existing lock owner to retain a valid lease. At the moment, any restart results in a a full lease expiry because the node id is not consistent. If the nodeid is configured through this logic then we can avoid the change https://github.com/apache/activemq-artemis/blob/main/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/jdbc/JdbcNodeManager.java#L70 Issue Time Tracking --- Worklog Id: (was: 922149) Time Spent: 0.5h (was: 20m) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=922137=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-922137 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 05/Jun/24 11:15 Start Date: 05/Jun/24 11:15 Worklog Time Spent: 10m Work Description: gtully commented on PR #4951: URL: https://github.com/apache/activemq-artemis/pull/4951#issuecomment-2149567599 Have you seen: https://github.com/apache/activemq-artemis/blob/576622571a839720d83d800b12a7f2b2448b30d9/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ReplicationPrimaryActivation.java#L171 with the zk locker we can have peer brokers that coordinate on a shared node id. it is called the coordinator-id in the zk activation config, but ends up as the node-id. With the potential for unknown backups with replication, the node id has to be reset. However this new config could make it simpler for pure peers, where there is no replication b/c the it is non persistent or uses a shared store. I guess we need to allow these to coexist or document that they must be used independently. Issue Time Tracking --- Worklog Id: (was: 922137) Time Spent: 20m (was: 10m) > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
[jira] [Work logged] (ARTEMIS-4545) Allow node ID to be configured
[ https://issues.apache.org/jira/browse/ARTEMIS-4545?focusedWorklogId=921548=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-921548 ] ASF GitHub Bot logged work on ARTEMIS-4545: --- Author: ASF GitHub Bot Created on: 31/May/24 14:09 Start Date: 31/May/24 14:09 Worklog Time Spent: 10m Work Description: AntonRoskvist opened a new pull request, #4951: URL: https://github.com/apache/activemq-artemis/pull/4951 This turned out to be quite a bit more involved than what I originally anticipated, please let me know if anything is missing or is otherwise looking strange Issue Time Tracking --- Worklog Id: (was: 921548) Remaining Estimate: 0h Time Spent: 10m > Allow node ID to be configured > -- > > Key: ARTEMIS-4545 > URL: https://issues.apache.org/jira/browse/ARTEMIS-4545 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In certain situations it would be beneficial to configure the node ID rather > than having it automatically generated. > For example, when using replication + failback if the primary server fails > the backup will take over. Then when the primary is restarted it will > initiate failback. However, if the primary broker's journal is damaged or > lost during the initial failure then it won't be able to initiate failback > because it won't have the same node ID as the backup. This kind of situation > is not uncommon in cloud environments where there is no persistent, attached > storage. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@activemq.apache.org For additional commands, e-mail: issues-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
