SEPURI-SAI-KRISHNA commented on PR #12595:
URL: https://github.com/apache/seatunnel/pull/12595#issuecomment-6146813932
Thanks @SEZ9 and @DanielLeens.
**One correction first, because it is the security-relevant half.** @SEZ9,
you wrote that my check settled that JDK 8 carries the same time-constant
`isEqual`. It is the other way round: there is **no JDK 8 on this machine**, so
I never checked it. I disassembled 11.0.32, 17.0.20 and 21.0.12, where the
length difference is folded into the accumulator. @DanielLeens disassembled
8u71 and 8u171 and found the opposite, an `if_icmpeq` on the two lengths then
an immediate `return false`. My original javadoc claimed 8u was verified and
was wrong. The leading-byte property holds on every shape; only the **length**
stays inferable on 8u, which is what the javadoc now says.
**Ask 1, mapping the invocation.** Recoverable, but not from the artifacts,
which carry only `{TestContainer}[2]`. The job log has it: the invocation
provider names each container as it starts, in a fixed order repeated per test
method.
```text
[1] Flink:1.18.0 pass [2] Flink:1.20.1 FAIL [3] SeaTunnel:dev pass [4]
Spark:3.3.0 pass
```
So `[2]` is **Flink 1.20.1**, matching the container you named on `dev` as
`[4]`, and both `Direct buffer memory` lines fall inside its windows. The part
I missed until I checked the order: **Flink 1.18.0 passes in the same job**, so
this is specific to the 1.20.1 image rather than to Flink.
That gave a root cause rather than a signature:
```text
io.netty EncoderException: OutOfMemoryError: Direct buffer memory
-> ConnectionInitException: STARTUP step 1, failed to send request
-> AllNodesFailedException: All 1 node(s) tried for query failed (20x)
-> job exits 1 -> the exit-code assertion fails
```
The driver cannot allocate a direct buffer for its first CQL frame in that
taskmanager, so no row is read. A direct-memory budget problem in the
container, not a Cassandra race.
**Ask 2, the tracking issue.** Filed as #12757, with the container mapping,
the exception chain and both reproductions, including `dev` head `b0f6feddf` on
run 38340962420 which I confirmed is red on `dev` itself.
It raises one point for a maintainer: #12732 quotes the **same** message as
a `TRUNCATE` race, yet on `dev` the only assertions able to print `expected:
<0>` are those two exit-code ones, and its patch adds no count assertion. Set
out in the issue to be reconciled, not as a claim they are wrong, since I have
not read their job log.
Agreed with @DanielLeens that a rerun cannot clear this while `dev` is red.
--
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]
