You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Reuven Lax (JIRA)" <ji...@apache.org> on 2018/11/02 19:59:00 UTC
[jira] [Commented] (BEAM-5928) ConcurrentModificationException from
RowCoderGenerator lazy caching
[ https://issues.apache.org/jira/browse/BEAM-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16673608#comment-16673608 ]
Reuven Lax commented on BEAM-5928:
----------------------------------
pr/6927 out for review
> ConcurrentModificationException from RowCoderGenerator lazy caching
> -------------------------------------------------------------------
>
> Key: BEAM-5928
> URL: https://issues.apache.org/jira/browse/BEAM-5928
> Project: Beam
> Issue Type: Bug
> Components: sdk-java-core
> Reporter: Benson Tucker
> Assignee: Reuven Lax
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Summary:
> RowCoderGenerator caches a delegate Coder<Row> once encode or decode is exercised, but there's not an API for caching this delegate eagerly.
> h3. Use Case:
> When creating several PCollections to perform distinct reads with the same schema, you might create one RowCoder.of(schema) before creating the list of PCollections / PCollectionsList. However, once the pipeline begins and rows arrive for encoding, these pipelines will simultaneously try to cache a delegate coder for the row's schema.
> h3. Workaround:
> You can force the eager caching of the code by exercising encode in the main application before creating PCollections using the RowCoder:
> {code:java}
> try {
> myRowCoder.encode(null, null);
> } catch (IOException | NullPointerException e) {
> // do nothing
> }
> {code}
> h3. Context:
> I've only encountered this during development with the direct runner.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)