DanielMorales9 opened a new issue, #32746:
URL: https://github.com/apache/beam/issues/32746

   ### What happened?
   
   I am trying to stream data from PubSub (with a throughput of 10-50 RPS) into 
an Iceberg Table (not partitioned) using the IcebergIO connector and Hive 
Metastore. 
   
   However, after some time, I see warning logs in the console like below:
   ```
   ...
   Operation ongoing in bundle for at least 40m00s without completing Current 
user step name: 
Managed.ManagedTransform/ManagedSchemaTransformProvider.ManagedSchemaTransform/IcebergWriteSchemaTransformProvider.IcebergWriteSchemaTransform/IcebergIO.WriteRows/Write
 Rows 
   Operation ongoing in bundle for at least 50m00s without completing Current 
user step name: 
Managed.ManagedTransform/ManagedSchemaTransformProvider.ManagedSchemaTransform/IcebergWriteSchemaTransformProvider.IcebergWriteSchemaTransform/IcebergIO.WriteRows/Write
 Rows 
   Operation ongoing in bundle for at least 01h00m00s without completing 
Current user step name: 
Managed.ManagedTransform/ManagedSchemaTransformProvider.ManagedSchemaTransform/IcebergWriteSchemaTransformProvider.IcebergWriteSchemaTransform/IcebergIO.WriteRows/Write
 Rows
   Operation ongoing in bundle for at least 01h10m00s without completing 
Current user step name: 
Managed.ManagedTransform/ManagedSchemaTransformProvider.ManagedSchemaTransform/IcebergWriteSchemaTransformProvider.IcebergWriteSchemaTransform/IcebergIO.WriteRows/Write
 Rows
   ...
   ```
   
   From the thread dump (see 
[threadump.txt](https://github.com/user-attachments/files/17333596/threadump.txt))
 it looks like a significant number of _DataflowWorkUnits_ threads (287) are in 
the `TIMED_WAITING` state, specifically waiting for a Hive client from the pool.
   ```
   [email protected]/java.lang.Object.wait(Native Method)
   app//org.apache.iceberg.ClientPoolImpl.get(ClientPoolImpl.java:133)
   ```
   
   However, I find it surprising that all these threads are attempting to 
create a new writer each time, which results in the concurrent reload of the 
table we saw above. Is this behavior expected? I suspect that the performance 
issues stem from the `RecordWriterManager` class not being thread-safe. 
Specifically, it appears that a race condition is occurring in this code 
snippet due to the `check-then-act` logic:  
https://github.com/apache/beam/blob/4cf99ea31aa2f3b4e8fa0da479939bbe92bd46dd/sdks/java/io/iceberg/src/main/java/org/apache/beam/sdk/io/iceberg/RecordWriterManager.java#L151-L161
   
   
   
   ### Issue Priority
   
   Priority: 2 (default / most bugs should be filed as P2)
   
   ### Issue Components
   
   - [ ] Component: Python SDK
   - [X] Component: Java SDK
   - [ ] Component: Go SDK
   - [ ] Component: Typescript SDK
   - [X] Component: IO connector
   - [ ] Component: Beam YAML
   - [ ] Component: Beam examples
   - [ ] Component: Beam playground
   - [ ] Component: Beam katas
   - [ ] Component: Website
   - [ ] Component: Infrastructure
   - [ ] Component: Spark Runner
   - [ ] Component: Flink Runner
   - [ ] Component: Samza Runner
   - [ ] Component: Twister2 Runner
   - [ ] Component: Hazelcast Jet Runner
   - [X] Component: Google Cloud Dataflow Runner


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to