[
https://issues.apache.org/jira/browse/ARTEMIS-3909?focusedWorklogId=796128&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-796128
]
ASF GitHub Bot logged work on ARTEMIS-3909:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 28/Jul/22 16:21
Start Date: 28/Jul/22 16:21
Worklog Time Spent: 10m
Work Description: clebertsuconic opened a new pull request, #4156:
URL: https://github.com/apache/activemq-artemis/pull/4156
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.
Issue Time Tracking
-------------------
Worklog Id: (was: 796128)
Remaining Estimate: 0h
Time Spent: 10m
> 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: 10m
> 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)
