[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Geoffrey Jacoby updated PHOENIX-4910:
-
Fix Version/s: 5.2.1
(was: 4.17.0)
(was: 5.2.0)
(was: 4.16.2)
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 5.2.1
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal updated PHOENIX-4910:
---
Fix Version/s: (was: 5.1.2)
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.17.0, 5.2.0, 4.16.2
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-4910:
--
Fix Version/s: (was: 4.16.1)
4.16.2
5.1.2
5.2.0
4.17.0
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.17.0, 5.2.0, 5.1.2, 4.16.2
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-4910:
---
Fix Version/s: (was: 4.15.1)
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 5.1.1, 4.16.1
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-4910:
---
Fix Version/s: (was: 4.16.0)
4.16.1
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.15.1, 5.1.1, 4.16.1
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-4910:
---
Fix Version/s: 4.16.0
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.15.1, 5.1.1, 4.16.0
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-4910:
---
Fix Version/s: (was: 5.1.0)
5.1.1
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.15.1, 5.1.1
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-4910:
---
Fix Version/s: (was: 4.15.0)
4.15.1
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 5.1.0, 4.15.1
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-4910:
Attachment: PHOENIX-4910.002.patch
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4910.001.patch, PHOENIX-4910.002.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-4910:
Description:
A user ran into a JVM bug which appears to have caused a RegionServer to crash
while running a topN aggregate query. This left a large number of files in
{{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
MappedByteBufferQueue will buffer results in memory up to 20MB by default
(controlled by {{phoenix.query.spoolThresholdBytes}}) and then start appending
them to a file. I'm seeing two things which could be improved:
* If the RS exits abnormally, there is no process to clean up files - would be
nice to register the {{deleteOnExit()}} hook to try to clean these up.
* There is no ability to control where MappedByteBufferQueue writes its spool
file - would be nice to use something other than /tmp (I think we have a
property to control this already in our config..)
FYI [~an...@apache.org]
was:
A user ran into a JVM bug which appears to have caused a RegionServer to crash
while running a topN aggregate query. This left a large number of files in
{{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
MappedByteBufferQueue will buffer results in memory up to 20MB by default
(controlled by {{phoenix.query.spoolThresholdBytes}}) and then start appending
them to a file. I'm seeing two things which could be improved:
* If the RS exist abnormally, there is no process to clean up files - would be
nice to register the {{deleteOnExit()}} hook to try to clean these up.
* There is no ability to control where MappedByteBufferQueue writes its spool
file - would be nice to use something other than /tmp (I think we have a
property to control this already in our config..)
FYI [~an...@apache.org]
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4910.001.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exits abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4910) Improvements to spooled MappedByteBufferQueue files
[
https://issues.apache.org/jira/browse/PHOENIX-4910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-4910:
Attachment: PHOENIX-4910.001.patch
> Improvements to spooled MappedByteBufferQueue files
> ---
>
> Key: PHOENIX-4910
> URL: https://issues.apache.org/jira/browse/PHOENIX-4910
> Project: Phoenix
> Issue Type: Bug
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4910.001.patch
>
>
> A user ran into a JVM bug which appears to have caused a RegionServer to
> crash while running a topN aggregate query. This left a large number of files
> in {{/tmp}} after the RS had gone away (due to a JVM SIGBUS crash).
> MappedByteBufferQueue will buffer results in memory up to 20MB by default
> (controlled by {{phoenix.query.spoolThresholdBytes}}) and then start
> appending them to a file. I'm seeing two things which could be improved:
> * If the RS exist abnormally, there is no process to clean up files - would
> be nice to register the {{deleteOnExit()}} hook to try to clean these up.
> * There is no ability to control where MappedByteBufferQueue writes its
> spool file - would be nice to use something other than /tmp (I think we have
> a property to control this already in our config..)
> FYI [~an...@apache.org]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
