ng
>>> al the time, so it processed the major part of the input documents in, I
>>> would say, an hour, and the rest in the remaining time).
>>>
>>> Is there anything we can do to improve this weird behaviour?
>>>
>>>
>:
>>
>>> Do you see any other exceptions in Stackdriver, e.g. (guess) OOM errors?
>>> "worker lost contact with the service" is commonly caused by OOM crashes,
>>> and GC thrashing could also cause network issues of the sort that you're
>>> s
:
>>
>>> Hi there,
>>>
>>> I'm running a pipeline in Google Cloud Dataflow that reads from GCS and
>>> writes into several BQ tables. This pipeline has been successfully used to
>>> load several TB of data from GCS to BQ.
>>>
>>
ading documents from GCS that are
>> "exploded" into several documents (they are multiplied by between 1 and 25
>> depending on the document type) in one of the steps to insert them into
>> several BQ tables. Example: I have one document of "type a" that is
>>
; exploded into three documents: "type a.1", "type a.2" and "type a.3."
>
> I also have performed successful executions of this kind several times,
> but in this specific case I am getting the following errors:
>
> java.io.IOException: Failed to close s
quot;
I also have performed successful executions of this kind several times, but
in this specific case I am getting the following errors:
java.io.IOException: Failed to close some writers at
org.apache.beam.sdk.io.gcp.bigquery.WriteBundlesToFiles.finishBundle(WriteBundlesToFiles.java:245)
Su
