DanielLeens commented on issue #10993:
URL: https://github.com/apache/seatunnel/issues/10993#issuecomment-4686421089

   The new dynamic-slot result is useful, and it narrows the question quite a 
bit.
   
   After checking the current engine code, there is one important detail here: 
once `dynamic-slot: true` is enabled, SeaTunnel forces the schedule strategy to 
`REJECT` internally. So this is no longer the same execution mode as your 
earlier `fixed slot + WAIT` setup, and the two runs cannot be compared as if 
only the slot count changed.
   
   Also, `UNKNOWABLE` in the running-job status is not direct proof that 
dynamic slot is "unlimited". In the current coordinator path, `UNKNOWABLE` is 
returned when the master can no longer find an active `JobMaster` for that job 
and also cannot immediately resolve a persisted job state. That points more to 
a possible job-lifecycle / state-visibility problem than to a simple "too many 
dynamic slots" explanation.
   
   So at this stage, this still needs a bit more evidence before we can call it 
a confirmed engine bug. To narrow it down, please share these 4 items for one 
specific job that becomes `UNKNOWABLE`:
   1. the exact master and worker `seatunnel.yaml` used in the dynamic-slot 
test after the config change
   2. the full master log around that job ID, from submission until it first 
appears as `UNKNOWABLE`
   3. the output of `/running-jobs` and, if available, that job's history / 
detail endpoint before and after the state changes
   4. whether the problem still reproduces if you lower concurrency first and 
then increase it step by step
   
   Your monitoring snapshot does not show obvious heap exhaustion on its own, 
so right now the stronger suspicion is a job-state / lifecycle issue in 2.3.11 
under this pressure pattern, not simply "dynamic slot has no upper bound".
   
   If you can provide the logs for one concrete `UNKNOWABLE` job ID, we can 
continue the analysis much more accurately.


-- 
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]

Reply via email to