[
https://issues.apache.org/jira/browse/ARTEMIS-3243?focusedWorklogId=616981&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-616981
]
ASF GitHub Bot logged work on ARTEMIS-3243:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 30/Jun/21 10:02
Start Date: 30/Jun/21 10:02
Worklog Time Spent: 10m
Work Description: gemmellr commented on a change in pull request #3633:
URL: https://github.com/apache/activemq-artemis/pull/3633#discussion_r661313800
##########
File path:
artemis-commons/src/test/java/org/apache/activemq/artemis/utils/ByteUtilTest.java
##########
@@ -39,6 +39,49 @@
private static Logger log = Logger.getLogger(ByteUtilTest.class);
+
+ @Test
+ public void testMixIDs1() {
+ long mixedID = ByteUtil.mixByteAndLong((byte)3, -1L); // just a note,
-1 is 0Xffffff....
+ Assert.assertEquals((byte)3, ByteUtil.getFirstByte(mixedID));
+
+ long mixedIDWithMaxValue = ByteUtil.mixByteAndLong((byte)3,
Long.MAX_VALUE);
+ // first byte is 03, all the rest is fff...
+ Assert.assertEquals(0x03ffffffffffffffL, mixedIDWithMaxValue);
+ // -1 and fff should return you the same value when mixing 03, I'm doing
this check just in case.
+ Assert.assertEquals(mixedIDWithMaxValue, mixedID);
Review comment:
You would only need 2 messages with IDs in that range to actually cause
issues though. Yes, its a very big number, but just dividing it by 256 and
silently assuming we can use those bits just seems fragile and likely to cause
issues later. Hard to find and fix issues. At the very least I'd expect to see
related changes elsewhere ensuring the broker can never actually generate such
IDs, as presumably right now it can.
Looking, the ID actually seems to be down to the store to decide rather than
the broker as a whole, so who is to say someone wont make a store that doesnt
assign IDs differently, even just starting nearer the end to verify rollover is
handled (something I've seen done elsewhere), or that its impossible a system
will ever generate that ID for some strange less typical reason.
Actually, it even seems from the code like the current journal ID handling
could potentially skip the number forward itself by up to 2^31-1 at a time with
its checkpointing behaviour. If so, that will burn those IDs fairly quickly.
Confirmed, I just burned several billion IDs in seconds while sending a mere
handful of non-persistent messages, by simply killing the broker. Looks like it
might do the same in other cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 616981)
Time Spent: 6h 40m (was: 6.5h)
> Enhance AMQP Mirror support with dual mirror
> --------------------------------------------
>
> Key: ARTEMIS-3243
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3243
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 2.17.0
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Fix For: 2.18.0
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> at the current Mirror version, we can only mirror into a single direction.
> With this enhancement the two (or more brokers) would be connected to each
> other, each one having its own ID, and each one would send updates to the
> other broker.
> The outcome is that if you just transferred producers and consumers from one
> broker into the other, the fallback would be automatic and simple. No need to
> disable and enable mirror options.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
