phanikumv commented on code in PR #68938:
URL: https://github.com/apache/airflow/pull/68938#discussion_r3466648692
##########
airflow-core/docs/authoring-and-scheduling/language-sdks/java.rst:
##########
@@ -669,6 +687,44 @@ All ``kwargs`` in the ``coordinators`` config entry are
passed to the
- Seconds to wait for the JVM subprocess to connect after launch.
Increase this if your
JVM startup is slow (e.g. on constrained hardware or with a large
classpath).
+.. note::
+
+ The ``[sdk]`` configuration is read at startup, so changes to
``coordinators`` or
+ ``queue_to_coordinator`` (for example adding ``jvm_args``) only take effect
after you restart the
+ scheduler (or ``airflow standalone``). A rebuilt bundle JAR, by contrast, is
picked up on the next
+ task launch without a restart, because a fresh JVM is spawned per task
instance.
+
+.. _java-sdk/macos:
+
+macOS setup
+-----------
+
+Two extra coordinator settings are needed when running tasks on macOS:
+
+* **Force the JVM onto IPv4.** The coordinator verifies that the task JVM owns
its callback socket. On
+ macOS a dual-stack JVM reports its local address in the IPv4-compatible form
(``::127.0.0.1``),
Review Comment:
The regression test (`test_matches_dual_stack_ipv4_mapped_connection` added
for issues #67781/#68147) says the dual-stack JVM actually shows up as
`::ffff:127.0.0.1`, which is the mapped form. And that form was
specifically fixed to be accepted.
So if the JVM uses the mapped form, the rejection this doc describes
shouldn't happen anymore — it was already fixed. Can you please clarify
--
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]
