[
https://issues.apache.org/jira/browse/PHOENIX-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16788387#comment-16788387
]
Chinmay Kulkarni commented on PHOENIX-5184:
-------------------------------------------
Please take a look at the PR. I'm not so familiar with the index-related code
paths so would especially appreciate an extra set of eyes to take a look at
those paths.
2 main points of concern/discussion for some of the changes I may have
inadvertently made are cases such as:
{code:java}
try (Closeable or AutoCloseable resource) {
AsyncMethod() // Async method using/depending on said resource
}
{code}
In this case, we have to be careful not to close the resource and thus avoid
try-with-resources. Are there better ways to prevent connection leaks in such
cases?
Mapper jobs such as _PhoenixIndexImportMapper_,
_PhoenixIndexPartialBuildMapper_, _PhoenixIndexImportDirectMapper_ each
implement the _cleanup_ method which closes opened resources, however, this
might not be called in case of an exception inside the map or setup. How should
we handle such cases in general?
Resource:
[https://stackoverflow.com/questions/10889152/setup-and-cleanup-methods-of-mapper-reducer-in-hadoop-mapreduce]
FYI [~tdsilva] [~vincentpoon] [~gjacoby] [~kozdemir]
> HBase and Phoenix connection leaks in Indexing code path, OrphanViewTool and
> PhoenixConfigurationUtil
> -----------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-5184
> URL: https://issues.apache.org/jira/browse/PHOENIX-5184
> Project: Phoenix
> Issue Type: Bug
> Reporter: Chinmay Kulkarni
> Assignee: Chinmay Kulkarni
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I was debugging a connection leak issue and ran into a few areas where there
> are connection leaks. I decided to take a broader look overall and see if
> there were other places where we leak connections and found some candidates.
> This is by no means an exhaustive search for connection leaks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
