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)