gaogaotiantian commented on code in PR #54258:
URL: https://github.com/apache/spark/pull/54258#discussion_r2801583031
##########
python/pyspark/worker_util.py:
##########
@@ -155,39 +155,42 @@ def setup_spark_files(infile: IO) -> None:
def setup_broadcasts(infile: IO) -> None:
"""
Set up broadcasted variables.
+ {
+ "conn_info": int | str | None,
+ "auth_secret": str | None,
+ "broadcast_variables": [
+ {
+ "bid": int,
+ "path": str | None,
+ }
+ ]
+ }
"""
if not is_remote_only():
from pyspark.core.broadcast import Broadcast, _broadcastRegistry
- # fetch names and values of broadcast variables
- needs_broadcast_decryption_server = read_bool(infile)
- num_broadcast_variables = read_int(infile)
- if needs_broadcast_decryption_server:
+ data = json.loads(utf8_deserializer.loads(infile))
Review Comment:
This is part of the effort to refactor the whole protocol. I'm doing it
piece by piece so eventually we can have a structured message from JVM. Ideally
a multi-phased message. All the initialization (probably the UDF definition)
should be sent in a single message. The message should be relatively resistant
to new changes. For example it won't stuck if we decide to add something new.
Or it should report a clear error when the message is not following the
protocol.
json is good in a sense that, if we decide to add something else to
broadcast variable protocol, it's easy. If we did it wrong, we can find it
quickly too. Otherwise we had to be really careful about where to insert the
`read_long` and if we did not do it correctly, the worker could stuck at an
arbitrary point.
This refactor actually eliminated some unnecessary fields. Our old protocol
is too fragile that no one is willing to touch it. I want to gradually convert
it to a more structured way. A single switch is a bit too dangerous.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
