[
https://issues.apache.org/jira/browse/ARTEMIS-3297?focusedWorklogId=596867&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-596867
]
ASF GitHub Bot logged work on ARTEMIS-3297:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 14/May/21 19:37
Start Date: 14/May/21 19:37
Worklog Time Spent: 10m
Work Description: michaelandrepearce commented on a change in pull
request #3580:
URL: https://github.com/apache/activemq-artemis/pull/3580#discussion_r632753627
##########
File path: artemis-server/src/test/resources/ConfigurationTest-full-config.xml
##########
@@ -406,6 +406,9 @@
<page-max-concurrent-io>17</page-max-concurrent-io>
<read-whole-page>true</read-whole-page>
<journal-directory>somedir2</journal-directory>
+ <journal-history-directory>history</journal-history-directory>
Review comment:
> files is good if you care about you max disk usage. But I think for
time, hours is too coarse. and seconds covers everything up to hours nicely.
Initial idea was for it to be coarse as it would be days/weeks retention,
intent is to time machine back after say an incident that gets found out after
the fact and work out what could have happened. I’m not sure how useful seconds
here would be tbh. That said if the value is a long having it just as simple ms
like retention is in kafka just simplifies config, everyone is able to convert
days/weeks to ms and the we have a simple config, not having to deal with
variants
--
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 596867)
Time Spent: 3h (was: 2h 50m)
> Historical Backup of Broker Data
> --------------------------------
>
> Key: ARTEMIS-3297
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3297
> Project: ActiveMQ Artemis
> Issue Type: New Feature
> Affects Versions: 2.17.0
> Reporter: Clebert Suconic
> Priority: Major
> Fix For: 2.18.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> We should keep historical backup of the journal data, and having tools to
> recover data in case of data loss.
>
> Data loss could mean by unbehaved client's (say you mistakenly acknowledged
> data and your code caused the message to disappear earlier), or even after
> eventual bugs on the broker.
>
> To activate the functionality, you have to specify journal-history-data on
> broker.xml.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
