Andrea Cosentino created CAMEL-24435:
----------------------------------------
Summary: camel-as2 - asynchronous MDN context attributes are
reused across requests on the same connection
Key: CAMEL-24435
URL: https://issues.apache.org/jira/browse/CAMEL-24435
Project: Camel
Issue Type: Bug
Components: camel-as2
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
Fix For: 4.23.0
The AS2 request handler creates its HttpContext once, outside the request loop:
{code:java}
@Override
public void run() {
LOG.info("Processing new AS2 request");
final HttpContext context = HttpCoreContext.create();
try {
while (!Thread.interrupted()) {
this.httpService.handleRequest(this.serverConnection, context);
HttpCoreContext coreContext = HttpCoreContext.castOrCreate(context);
...
String recipientAddress =
coreContext.getAttribute(AS2AsynchronousMDNManager.RECIPIENT_ADDRESS,
String.class);
if (recipientAddress != null && config != null) {
// Send the MDN asynchronously.
{code}
The same context object is reused for every request handled on that connection.
ResponseMDN sets RECIPIENT_ADDRESS and ASYNCHRONOUS_MDN on it while handling a
request that asked for an asynchronous receipt, and nothing removes them
afterwards.
A subsequent request on the same connection that does *not* ask for an
asynchronous MDN therefore still finds a non-null recipientAddress, and the
handler dispatches another asynchronous MDN - carrying whatever multipart
report is still stored under ASYNCHRONOUS_MDN - to the address supplied by the
earlier request.
Proposal: clear RECIPIENT_ADDRESS and ASYNCHRONOUS_MDN from the context after
the send block, or create a fresh HttpCoreContext for each iteration of the
loop. A test that drives two requests over one connection, the first requesting
an asynchronous MDN and the second not, would cover it.
Split out of CAMEL-24429, which was originally filed covering both this and the
ResponseMDN instance-field issue. They share the theme of per-request state
outliving its request, but they are separate defects with separate fixes, and
keeping them apart keeps CAMEL-24429's scope precise.
Note this touches the same listener loop as CAMEL-24417, so the two changes
should be sequenced to avoid a conflict.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
