[
https://issues.apache.org/jira/browse/BEAM-7874?focusedWorklogId=291158&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-291158
]
ASF GitHub Bot logged work on BEAM-7874:
----------------------------------------
Author: ASF GitHub Bot
Created on: 08/Aug/19 10:50
Start Date: 08/Aug/19 10:50
Worklog Time Spent: 10m
Work Description: robertwb commented on pull request #9218: [BEAM-7874],
[BEAM-7873] Distributed FnApiRunner bugfixs
URL: https://github.com/apache/beam/pull/9218#discussion_r311972031
##########
File path: sdks/python/apache_beam/runners/portability/fn_api_runner.py
##########
@@ -1319,55 +1320,62 @@ def stop_worker(self):
@WorkerHandler.register_environment(common_urns.environments.DOCKER.urn,
beam_runner_api_pb2.DockerPayload)
class DockerSdkWorkerHandler(GrpcWorkerHandler):
+
+ _lock = threading.Lock()
Review comment:
> Yes, this is a workaround for subprocess.
Comments would be good for future readers of this code.
> I tried to add a function to handle calls to subprocess, but, I was not
able to find a good way to handle it. With `DockerSdkWorkerHandler`, we can
lock `start_worker()`, but we cannot lock `start_worker()` with
`SubprocessSdkWorkerHandler` handler. We should lock `subprocess.Popen()` only
with `SubprocessSdkWorkerHandler`, if we lock the whole `start_worker()`
function, it waits a worker to finish job, so the pipeline gets stuck.
I meant moving the lock out of DockerSdkWorkerHandler and
SubprocessSdkWorkerHandler to a common place, e.g. a global _subprocess_lock.
> In fact, I doubt `DockerSdkWorkerHandler` works with FnApi at the moment.
FnApi doesn't stage any artifacts, so docker bootstrap fails and container
cannot be created.
It does work; this is how we run Java pipelines on the FnApiRunner.
> I will make a change to `DockerSdkWorkerHandler` soon and create only one
container and handle multithreading/processing when a job running within
container,
For all SDKs?
> so we can get rid of lock here for `DockerSdkWorkerHandler`.
The lock is a log against all other calls to subprocess.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 291158)
Time Spent: 2h 20m (was: 2h 10m)
> FnApi only supports up to 10 workers
> ------------------------------------
>
> Key: BEAM-7874
> URL: https://issues.apache.org/jira/browse/BEAM-7874
> Project: Beam
> Issue Type: Bug
> Components: sdk-py-core
> Reporter: Hannah Jiang
> Assignee: Hannah Jiang
> Priority: Blocker
> Fix For: 2.15.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Because max_workers of grpc servers are hardcoded to 10, it only supports up
> to 10 workers, and if we pass more direct_num_workers greater than 10,
> pipeline hangs, because not all workers get connected to the runner.
> [https://github.com/apache/beam/blob/master/sdks/python/apache_beam/runners/portability/fn_api_runner.py#L1141]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
