[
https://issues.apache.org/jira/browse/ARTEMIS-3909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572564#comment-17572564
]
ASF subversion and git services commented on ARTEMIS-3909:
----------------------------------------------------------
Commit e44bd5266f0bc526be6ff6ec266050bb6f71dea0 in activemq-artemis's branch
refs/heads/main from Clebert Suconic
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=e44bd5266f ]
ARTEMIS-3909 Move RoutingContext::processReferences as a static method in
PostOffice
We were lucky that processReferences was pretty much a static operation, hence
I am moving it away from RoutingContext both for clarity and avoiding state
being needed on that method.
If state was needed as part of processReferences you would had a pretty nasty
bug as the IOCallback could introduce a race where a send would change the
state while the IO was pending.
> Move RoutingContext::processReferences to PostOfficeImpl
> --------------------------------------------------------
>
> Key: ARTEMIS-3909
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3909
> Project: ActiveMQ Artemis
> Issue Type: Task
> Reporter: Clebert Suconic
> Assignee: Clebert Suconic
> Priority: Major
> Fix For: 2.25.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reasoning:
> - We reuse the Routing Context as an optimization on the ServerSession.
> - By the time the Routing is done, we will process the references on a IO
> callback.
> - if anyone used any state in between the Routing and Storage, you could have
> an invalid operation.
> We were lucky that the method processReferences in PostOffice was pretty much
> static and no actual bug happened because of that, however I almost thought
> we had something scary going on.
> So, to avoid this kind of issue ever being introduced in the codebase I am
> moving the processReferences away from RoutingContext.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
