[
https://issues.apache.org/jira/browse/ARTEMIS-3243?focusedWorklogId=620014&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-620014
]
ASF GitHub Bot logged work on ARTEMIS-3243:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 07/Jul/21 14:58
Start Date: 07/Jul/21 14:58
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_r665454744
##########
File path:
artemis-commons/src/test/java/org/apache/activemq/artemis/utils/ByteUtilTest.java
##########
@@ -376,6 +367,21 @@ public void testIntToByte() {
}
}
+ @Test
+ public void testLongToByte() {
+ for (int i = 0; i < 1000; i++) {
Review comment:
Predictable is good in the sense that you fully verify an expected case
and you can see entirely what that case is, and very likely any failure will
make it immediately clear what went wrong. As-is, if it fails youd have to
first work back to try and even figure out what the long even was and then
which bit was wrong etc. Ok, its not likely to be ByteBuffer, but its still
using random other code to generate a value and verify whats already a known
expected outcome.
If you want some random you could always do both....have specific [corner]
case(s) with known byte result(s) to fully verify their expected behaviour, and
a random for some randomness.
Mainly I was just saying it doesnt seem like it needs 1000 attempts on every
test run rather than a few. I dont think thats likely to provide any more
confidence in it really. I mean, ok its going to be silly-fast, but its still
not really all that useful.
--
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: 620014)
Time Spent: 17h 20m (was: 17h 10m)
> 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: 17h 20m
> 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)
