WMK666666 commented on PR #29595:
URL: https://github.com/apache/camel/pull/29595#issuecomment-6815437474
Both points are in 80d7804.
**1. The exchange is no longer handed to the workers.** You are right that
the values are the same for every
document, so they are now resolved once, on the thread that owns the
exchange, into a small immutable holder:
- `OcrSettings resolveOcrSettings(Exchange)` holds the two decisions: the
endpoint configuration first, then
the two headers over it, exactly the precedence that was there before. It
sits where
`applyConfigurationToOptions` used to read the headers.
- `processBatchConversion` and `processBatchStructuredData` call it once,
before the executor is created, and
pass the holder into `convertDocumentsBatch`/`convertStructuredDataBatch`
instead of the exchange. Neither
of those two methods mentions `exchange` any more (checked: zero
occurrences in both bodies), so no worker
touches it, and a cancelled task that keeps running has nothing to read.
- `buildConvertRequest`, `buildStructuredDataRequest` and
`applyConfigurationToOptions` take the holder, so
the request cannot be built from an exchange at all any more — there is no
`Exchange` overload left to
reintroduce the same bug from.
- The single-document paths call `resolveOcrSettings(exchange)` where they
already have the exchange
(`convertUsingDoclingServe`, `processConvertToJson`,
`processExtractStructuredData`,
`processSubmitAsyncConversion`, `extractMetadataUsingApi`), so their
behaviour is unchanged.
The CLI path is untouched: `buildDoclingCommand` is built once per message
on the message's own thread, and
that path renders the decision as `--no-ocr` / `--ocr-lang`.
**2. The `enableOCR=false` rule is covered**, with the two cases you named —
`commandFor(OCR_OFF, null, "es")`
and `serveOptions(OCR_OFF, null, "es")`, i.e. no `EnableOCR` header, only a
language, on an endpoint that
disabled OCR: `--no-ocr` and no `--ocr-lang`, `doOcr=false` and no language.
Reverse-checked: deleting the `if (doOcr == null &&
!configuration.isEnableOCR())` fallback in
`resolveOcrSettings` fails exactly
`aLanguageHeaderDoesNotTurnOnOcrThatTheEndpointDisabledInTheServeRequest`
and leaves the other thirteen green — without it the language header would
set `doOcr=true` for that
message. The CLI case stays green either way, as it reads `isEnableOCR()`
directly.
`DoclingOcrHeadersTest`: 14 tests green. `mvn -pl
components/camel-ai/camel-docling test`: 100 tests, 2
failures, both `DoclingCustomArgsValidationTest` on Windows (`/etc/cron.d`
is not an absolute path there),
the same two that fail without this change. `formatter:validate` and
`impsort:check` pass.
**3. The upgrade-guide entry** stays where it is; #29591 and #29594 append
their own at the end of the same
file, so whichever lands second gets the trivial rebase. Happy to do it here
if this one comes in first.
The description is updated for the holder — the "Change" section explains
why the headers are read before
the workers start, and the test table gained the two new cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
