[
https://issues.apache.org/jira/browse/BEAM-5928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16670401#comment-16670401
]
Reuven Lax commented on BEAM-5928:
----------------------------------
I believe the correct fix here is probably to change to ConcurrentHashMap. So
replace
private static Map<UUID, Coder<Row>> generatedCoders = Maps.newHashMap();
with
private static Map<UUID, Coder<Row>> generatedCoders = Maps.newConcurrentMap();
> 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
>
> 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)
