[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Open (was: Patch Available) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Attachment: HIVE-19847.3.patch > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Patch Available (was: Open) There seems to be a lot of interest in multi-threading varying aspects of the HiveServer2 application, but everyone seems to be doing it there own way. I've put forward a patch that I hope can start the conversation on coming up with a more holistic approach to tackling this. > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Release Note: Fix FindBugs and CheckStyle Errors Status: Patch Available (was: Open) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Attachment: HIVE-19847.4.patch > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Open (was: Patch Available) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Patch Available (was: Open) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Attachment: HIVE-19847.5.patch > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Open (was: Patch Available) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Attachment: HIVE-19847.6.patch > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch, HIVE-19847.6.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Open (was: Patch Available) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch, HIVE-19847.6.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Release Note: (was: Fix FindBugs and CheckStyle Errors) Status: Patch Available (was: Open) Trying this again... patch didn't build but I also didn't change anything. > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch, > HIVE-19847.3.patch, HIVE-19847.4.patch, HIVE-19847.5.patch, HIVE-19847.6.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing tear down and setup. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Patch Available (was: Open) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Attachment: HIVE-19847.1.patch > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Attachment: HIVE-19847.2.patch > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Patch Available (was: Open) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Status: Open (was: Patch Available) > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HIVE-19847) Create Separate getInputSummary Service
[ https://issues.apache.org/jira/browse/HIVE-19847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] BELUGA BEHR updated HIVE-19847: --- Description: The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on a life of its own. We should consider separating out the various components into their own classes. For this ticket, I propose separating out the {{getInputSummary}} functionality into its own class. There are several issues with the current implementation: # It is [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. Only one query can get file input summary at a time. For a query which deals with a large data set with a large number of files, this can block other queries for a long period of time. This is especially painful when most queries use a small data set, but a large data set is submitted on occasion. # For each query, time is spend setting up and tearing down a ThreadPool # It uses deprecated code I propose breaking it out into its own class and creating a single thread pool that all queries pull from. In this way, the bottle neck will be one the number of available threads, not on a single query and if a big query is running and a small query is also submitted, the smaller query will be able to proceed. In regards to setup/teardown... if a query uses 15 threads to perform this summary action, then finishes, it will tear down the threads, the next query may immediate create 15 new threads for processing. With a single pool, those threads are never performing tear down and setup. was: The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on a life of its own. We should consider separating out the various components into their own classes. For this ticket, I propose separating out the {{getInputSummary}} functionality into its own class. There are several issues with the current implementation: # It is [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. Only one query can get file input summary at a time. For a query which deals with a large data set with a large number of files, this can block other queries for a long period of time. This is especially painful when most queries use a small data set, but a large data set is submitted on occasion. # For each query, time is spend setting up and tearing down a ThreadPool # It uses deprecated code I propose breaking it out into its own class and creating a single thread pool that all queries pull from. In this way, the bottle neck will be one the number of available threads, not on a single query and if a big query is running and a small query is also submitted, the smaller query will be able to proceed. > Create Separate getInputSummary Service > --- > > Key: HIVE-19847 > URL: https://issues.apache.org/jira/browse/HIVE-19847 > Project: Hive > Issue Type: Improvement > Components: HiveServer2 >Affects Versions: 3.0.0, 4.0.0 >Reporter: BELUGA BEHR >Assignee: BELUGA BEHR >Priority: Major > Attachments: HIVE-19847.1.patch, HIVE-19847.2.patch > > > The Hive {{org.apache.hadoop.hive.ql.exec.Utilities.java}} file has taken on > a life of its own. We should consider separating out the various components > into their own classes. For this ticket, I propose separating out the > {{getInputSummary}} functionality into its own class. > There are several issues with the current implementation: > # It is > [synchronized|https://github.com/apache/hive/blob/f27c38ff55902827499192a4f8cf8ed37d6fd967/ql/src/java/org/apache/hadoop/hive/ql/exec/Utilities.java#L2383]. > Only one query can get file input summary at a time. For a query which > deals with a large data set with a large number of files, this can block > other queries for a long period of time. This is especially painful when > most queries use a small data set, but a large data set is submitted on > occasion. > # For each query, time is spend setting up and tearing down a ThreadPool > # It uses deprecated code > I propose breaking it out into its own class and creating a single thread > pool that all queries pull from. In this way, the bottle neck will be one > the number of available threads, not on a single query and if a big query is > running and a small query is also submitted, the smaller query will be able > to proceed. > In regards to setup/teardown... if a query uses 15 threads to perform this > summary action, then finishes, it will tear down the threads, the next query > may immediate create 15 new threads for processing. With a single pool, > those threads are never performing