[
https://issues.apache.org/jira/browse/ARTEMIS-4164?focusedWorklogId=891993&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-891993
]
ASF GitHub Bot logged work on ARTEMIS-4164:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 23/Nov/23 10:57
Start Date: 23/Nov/23 10:57
Worklog Time Spent: 10m
Work Description: gtully commented on PR #4688:
URL:
https://github.com/apache/activemq-artemis/pull/4688#issuecomment-1824222213
It is a little more complicated b/c management is optional but I am thinking
it may be a good idea to first attempt reload via acceptorcontrol and if that
does not exist revert to calling the acceptor directly. the benefit of going
via the management control is that there is an audit log for the reload op.
Issue Time Tracking
-------------------
Worklog Id: (was: 891993)
Time Spent: 20m (was: 10m)
> Auto reload acceptor SSL keystores on change
> --------------------------------------------
>
> Key: ARTEMIS-4164
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4164
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.27.0
> Reporter: Gary Tully
> Priority: Major
> Labels: Netty, TLS
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In ARTEMIS-400 we added a jmx operation to reload ssl context configuration.
> It would make sense to trigger this automatically by default when a change is
> detected. We have the file watcher and can register an entry per keystore
> reference on acceptor creation.
> I think this should be the default but we can have a autoReload config option
> to disable it but it may be sufficient to depend on the file watch period to
> disable this feature?
> h1.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
