sangkyoonnam opened a new issue, #1311: URL: https://github.com/apache/flink-agents/issues/1311
### Search before asking - [x] I searched in the [issues](https://github.com/apache/flink-agents/issues) and found nothing similar. ### Description When continuation execution is enabled on JDK 21, the Agent operator doesn't enforce `max-in-flight-input-records`. In my Java ReAct Quickstart runs, JDK 21 with two Ollama slots printed no results in 10 minutes; JDK 17 with one slot printed its first result 87 s after the first input. The JDK 21 run with two Ollama slots logged an `_input_event` and a `_chat_request_event` for each of the 3,033 distinct records in `input_data.txt`, all within about 32 s of the first input. Calls already queued in the continuation executor's FIFO work queue stay ahead of later follow-up calls, so a record's second chat call can wait behind the first calls of many other records. Setting `max-in-flight-input-records: 4` doesn't help today: 3,033 runs still started, with no output in 6.7 minutes. The capacity check in `ActionExecutionOperator.processElement` yields through the mailbox while `inFlightInputRecords >= maxInFlightInputRecords`, but only on the parallel-engine branch, and `configuration.md` says the limit is ignored by continuation-based execution and plans containing Python Actions. The 0.4 artifacts, built with JDK 21 since #1295 (for #1292), include the continuation runtime, which is selected on JDK 21 with the required export option; the 0.3.0 and 0.3.1 artifacts didn't include it. I have a fix on top of #1310 that applies the admission wait to continuation and serial execution, the way `AsyncWaitOperator` waits for its capacity. It sets the incoming record's key again after waiting, releases the budget of inputs that trigger no Actions, and keeps a key busy until its input finishes. With `max-in-flight-input-records: 4`, the Quickstart started 13 runs, each under its own key, and printed 9 results in 6.7 minutes, the first after 70 s. With the default of 100, it started 100 runs and printed nothing in 9.5 minutes. The fix leaves FIFO scheduling unchanged; the JDK 17 parallel engine prioritizes queued tasks by record arrival order. I'd open the fix after 0.4 because it changes input admission in continuation and serial execution, unless you'd like it considered for 0.4. For 0.4, a note about this limitation in the Quickstart may be enough. For a separate PR on the slow first results, should I start by lowering the Quickstart's limit or by changing continuation scheduling to favor earlier records? cc @eemario @wenjin272 ### How to reproduce 1. From a checkout of `60bf8cd0`, build with JDK 21 (`./tools/build.sh -j`) and copy `dist/flink-2.3/target/flink-agents-dist-flink-2.3-0.4-SNAPSHOT.jar` (not `-thin`) into `$FLINK_HOME/lib` of Flink 2.3.0. Append `--add-exports=java.base/jdk.internal.vm=ALL-UNNAMED` to `env.java.opts.all` and start the cluster on JDK 21. 2. Start Ollama with `qwen3:8b` and `OLLAMA_NUM_PARALLEL=2`. With one slot, the example's 120 s request timeout failed the JDK 21 job within three minutes, so I used two to keep the timeout out of the comparison. 3. Run `$FLINK_HOME/bin/flink run -p 1 -c org.apache.flink.agents.examples.ReActAgentExample examples/target/flink-agents-examples-0.4-SNAPSHOT.jar` and watch the TaskManager `.out` file and `{log.file}.trace-log.log`. 4. Optionally add the following to `$FLINK_HOME/conf/config.yaml`, restart the cluster and run it again. The limit still doesn't throttle admission: 3,033 runs start. ```yaml agent: max-in-flight-input-records: 4 ``` ### Version and environment flink-agents main at `60bf8cd0`, built with Corretto 21.0.11. Flink 2.3.0 standalone session cluster with parallelism 1, on Corretto 21.0.11, and on Corretto 17.0.14 for the comparison. Ollama 0.34.4 with `qwen3:8b`, macOS 15.3.1 on Apple M4. ### Are you willing to submit a PR? - [x] I'm willing to submit a PR! -- 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]
