You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Ankit Singhal (Jira)" <ji...@apache.org> on 2021/06/07 14:55:04 UTC
[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 [~ankit@apache.org]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)