You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by GitBox <gi...@apache.org> on 2021/03/01 12:46:35 UTC

[GitHub] [arrow] alamb opened a new pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

alamb opened a new pull request #9605:
URL: https://github.com/apache/arrow/pull/9605


   # Rationale
   
   As spotted / articulated by @edrevo https://github.com/apache/arrow/pull/9523#issuecomment-786911328, the intermixing of `crossbeam` channels (not designed for `async` and can block task threads) and `async` code such as DataFusion can lead to deadlock.
   
   At least one of the crossbeam uses predates DataFusion being async (e.g. the one in the parquet reader). The use of crossbeam in the repartition operator in #8982 may have resulted from the re-use of the same pattern.
   
   # Changes
   
   1. Removes the use of crossbeam channels from DataFusion (in `RepartitionExec` and `ParquetExec`) and replace with tokio channels (which are designed for single threaded code).
   2. Removes `crossbeam` dependency entirely
   3. Removes use of `multi_thread`ed executor in tests (e.g. `#[tokio::test(flavor = "multi_thread")]`) which can mask hangs
   
   # Kudos / Thanks
   
   This PR incorporates the work of @seddonm1 from https://github.com/apache/arrow/pull/9603 and @edrevo in  https://github.com/edrevo/arrow/tree/remove-crossbeam (namely 97c256c4f76b8185311f36a7b27e317588904a3a). A big thanks to both of them for their help in this endeavor. 
   
   


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] github-actions[bot] commented on pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#issuecomment-787923096


   https://issues.apache.org/jira/browse/ARROW-11802


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] Dandandan commented on a change in pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
Dandandan commented on a change in pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#discussion_r584891340



##########
File path: rust/datafusion/src/physical_plan/repartition.rs
##########
@@ -48,9 +51,13 @@ pub struct RepartitionExec {
     input: Arc<dyn ExecutionPlan>,
     /// Partitioning scheme to use
     partitioning: Partitioning,
-    /// Channels for sending batches from input partitions to output partitions
-    /// there is one entry in this Vec for each output partition
-    channels: Arc<Mutex<Vec<(Sender<MaybeBatch>, Receiver<MaybeBatch>)>>>,
+    /// Channels for sending batches from input partitions to output partitions.
+    /// Key is the partition number
+    channels: Arc<

Review comment:
       So ok if it's needed, but I just wasn't sure :+1: 




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] alamb commented on a change in pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
alamb commented on a change in pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#discussion_r584686515



##########
File path: rust/datafusion/src/physical_plan/repartition.rs
##########
@@ -48,9 +51,13 @@ pub struct RepartitionExec {
     input: Arc<dyn ExecutionPlan>,
     /// Partitioning scheme to use
     partitioning: Partitioning,
-    /// Channels for sending batches from input partitions to output partitions
-    /// there is one entry in this Vec for each output partition
-    channels: Arc<Mutex<Vec<(Sender<MaybeBatch>, Receiver<MaybeBatch>)>>>,
+    /// Channels for sending batches from input partitions to output partitions.
+    /// Key is the partition number
+    channels: Arc<

Review comment:
       Note @Dandandan  asked about using a  `HashMap` vs some other structure. It is a `HashMap` for reasons explained by @edrevo here: https://github.com/edrevo/arrow/commit/97c256c4f76b8185311f36a7b27e317588904a3a#r47626396




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] alamb closed pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
alamb closed pull request #9605:
URL: https://github.com/apache/arrow/pull/9605


   


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] alamb commented on a change in pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
alamb commented on a change in pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#discussion_r584901754



##########
File path: rust/datafusion/src/physical_plan/repartition.rs
##########
@@ -48,9 +51,13 @@ pub struct RepartitionExec {
     input: Arc<dyn ExecutionPlan>,
     /// Partitioning scheme to use
     partitioning: Partitioning,
-    /// Channels for sending batches from input partitions to output partitions
-    /// there is one entry in this Vec for each output partition
-    channels: Arc<Mutex<Vec<(Sender<MaybeBatch>, Receiver<MaybeBatch>)>>>,
+    /// Channels for sending batches from input partitions to output partitions.
+    /// Key is the partition number
+    channels: Arc<

Review comment:
       Thanks @Dandandan 
   
   The use is here: https://github.com/apache/arrow/pull/9605/files#diff-b9b79e3b35bc8bfb43040ada3a4382bd0a0017ca1b1e8135be8fb310ff095674R229 
   
   Basically this code sets up all input and outputs channels for all of the partitions and then hands out one receiver at a time in some arbitrary order (depending on the `partition` argument).
   
    `UnboundedReceiver` https://docs.rs/tokio/1.2.0/tokio/sync/mpsc/struct.UnboundedReceiver.html doesn't implement `Clone` (as it is multiple producer *single* consumer)
   
   I suspect with some more thought a different structure could be used, but I couldn't convince myself it was a valuable use of time. 




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] alamb commented on pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
alamb commented on pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#issuecomment-789662262


   I checked this code out locally, merged from apache/master and reran the tests -- all still passes so merging in. 
   
   


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] alamb commented on a change in pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
alamb commented on a change in pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#discussion_r584685022



##########
File path: rust/datafusion/src/physical_plan/repartition.rs
##########
@@ -199,14 +211,12 @@ impl ExecutionPlan for RepartitionExec {
                     }
 
                     // notify each output partition that this input partition has no more data
-                    for channel in channels.iter_mut().take(num_output_partitions) {
-                        let tx = &mut channel.0;
+                    for (_, tx) in txs {
                         tx.send(None)
                             .map_err(|e| DataFusionError::Execution(e.to_string()))?;
                     }
                     Ok(())
                 });
-                tokio::task::yield_now().await;

Review comment:
       this is the workaround added in https://github.com/apache/arrow/pull/9580 and it is now removed in favor of what we think is the fix of the root cause




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] Dandandan commented on pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
Dandandan commented on pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#issuecomment-789670134


   I also tested partitioning parquet & reading parquet from datafusion - all worked OK :+1: 


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



[GitHub] [arrow] Dandandan commented on a change in pull request #9605: ARROW-11802: [Rust][DataFusion] Remove use of crossbeam channels to avoid potential deadlocks

Posted by GitBox <gi...@apache.org>.
Dandandan commented on a change in pull request #9605:
URL: https://github.com/apache/arrow/pull/9605#discussion_r584888850



##########
File path: rust/datafusion/src/physical_plan/repartition.rs
##########
@@ -48,9 +51,13 @@ pub struct RepartitionExec {
     input: Arc<dyn ExecutionPlan>,
     /// Partitioning scheme to use
     partitioning: Partitioning,
-    /// Channels for sending batches from input partitions to output partitions
-    /// there is one entry in this Vec for each output partition
-    channels: Arc<Mutex<Vec<(Sender<MaybeBatch>, Receiver<MaybeBatch>)>>>,
+    /// Channels for sending batches from input partitions to output partitions.
+    /// Key is the partition number
+    channels: Arc<

Review comment:
       I didn't follow the answer completely; why do we need to remove it? 
   I think `UnboundedSender` is cheap to clone and cheap to keep in memory for the duration of `RepartitionStream`?
   
   But maybe I would need to play with the code more to see why it is needed per se.




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org