apache / apache/parquet-java

Thread safety bug in CodecFactory

Offen
#2,669 9 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Component: Java Component: Parquet Priority: Major Type: bug
Vorherrschende Sprache
Java
Sterne
3.1k
Forks
1.6k
Ø Merge
3 T. 12 Std.
Gemergte PRs (30 T.)
33

Beschreibung

The code for returning Compressor objects to the caller goes to some lengths to achieve thread safety, including keeping Codec objects in an Apache Commons pool that has thread-safe borrow semantics.  This is all undone by the BytesCompressor and BytesDecompressor Maps in org.apache.parquet.hadoop.CodecFactory which end up caching single compressor and decompressor instances due to code in CodecFactory@getCompressor and CodecFactory@getDecompressor.  When the caller runs multiple threads, those threads end up sharing compressor and decompressor instances.

For compressors based on Xerial Snappy this bug has no effect because that library is itself thread safe.  But when BuiltInGzipCompressor from Hadoop is selected for the CompressionCodecName.GZIP case, serious problems ensue.  That class is not thread safe and sharing one instance of it between threads produces both silent data corruption and JVM crashes.

To fix this situation, parquet-mr should stop caching single compressor and decompressor instances.

**Reporter**: [James Turton](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dzamo)
#### Related issues:
- [Parquet CodecFactory thread safety bug](https://issues.apache.org/jira/browse/DRILL-8139) (fixes)

**Note**: *This issue was originally created as [PARQUET-2126](https://issues.apache.org/jira/browse/PARQUET-2126). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Rechercherichtung

Beginne in org.apache.parquet.hadoop.CodecFactory, insbesondere bei getCompressor und getDecompressor, und verfolge, wie die BytesCompressor- und BytesDecompressor-Maps mit dem Apache Commons pool interagieren. Als abgeschlossen gilt die Aufgabe, wenn Compressor- und Decompressor-Instanzen nicht länger als jeweils eine einzige gemeinsam genutzte Instanz zwischengespeichert werden, sodass nebenläufige GZIP-Aufrufer den nicht threadsicheren BuiltInGzipCompressor nicht gemeinsam verwenden können.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
java
Bereich
backend
Issue-Typ
Bug
Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Aktivitätsstatus
Veraltet
Klarheit
Klar beschrieben
Anfängerfreundlichkeit
42/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.