[ 
https://issues.apache.org/jira/browse/ARTEMIS-4709?focusedWorklogId=913751&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-913751
 ]

ASF GitHub Bot logged work on ARTEMIS-4709:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 09/Apr/24 17:13
            Start Date: 09/Apr/24 17:13
    Worklog Time Spent: 10m 
      Work Description: jbertram commented on PR #4871:
URL: 
https://github.com/apache/activemq-artemis/pull/4871#issuecomment-2045717014

   I've gone back and forth on this in my mind a few times. 
   
   I see your points, but if this functionality "becomes part of lots of 
deployments" then changing the way it's configured will be a breaking change 
for users which won't be a good experience. If the configuration is part of the 
core schema then they can get auto-completion (depending on the config editor 
they use) and validation.
   
   The code will be shipped with the broker either way. Whether it is optional 
can depend on configuration regardless of it it is a plugin.
   
   Generally speaking, I see plugins as a way for _users_ to add functionality 
to the broker.
   
   Personally I think this makes sense in the core broker.




Issue Time Tracking
-------------------

    Worklog Id:     (was: 913751)
    Time Spent: 1h 50m  (was: 1h 40m)

> Add a plugin to provide periodic expiry of connections on a per acceptor basis
> ------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-4709
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4709
>             Project: ActiveMQ Artemis
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 2.33.0
>            Reporter: Gary Tully
>            Assignee: Gary Tully
>            Priority: Major
>             Fix For: 2.34.0
>
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> When credential rotation needs to be enforced, active connections need to be 
> terminated on some timeline to ensure credentials are reevaluated. There are 
> management apis that can be used but these require some intervention.
> In addition to enforce some SLA around duration of connections, having an 
> easy way to limit connections to a given maximum period can be helpful.
> A plugin that will be applied on an per acceptor basis, that can be used to 
> disconnect connections that have lived for some period can provide a nice 
> building block for these use cases.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to