hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Liochon (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-9987) Remove some synchronisation points in HConnectionManager
Date Tue, 17 Dec 2013 10:19:08 GMT

    [ https://issues.apache.org/jira/browse/HBASE-9987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850314#comment-13850314
] 

Nicolas Liochon edited comment on HBASE-9987 at 12/17/13 10:19 AM:
-------------------------------------------------------------------

bq. we just miss cache a few times more for a better perf overall?
It's difficult to be sure. But let say that if someone just removed the entry from the cache,
it makes sense to to recheck again (and to add the entry again to be cache)... I feel that
the shorter the synchronisation time the better it is, but there is nothing proven.

bq. There seems to be a bit of dodgy updating now we no longer have sync blocks. 
I think there are two things we should do:
 - removing the force delete: it's just bad imho: because someone does not want to use the
cache, it removes the entry for everybody! As well, we're doing it inside the retry loop.
That's strange.
 - when we use meta, instead of doing: ??loc = call meta; cache(loc); return getCache()??
we should do ??loc = call meta; cache(loc); return loc??. That's what we're doing outside
of the lock actually. It's the prefect implementation that leads us to the logic. I'm waiting
for the reverseScan before removing the prefect (this way we will do a single call instead
of two as today). But may be I should remove the prefect immediately, keeping the two calls.
The simplest implementation would just be removing all the code that is today in the lock.




was (Author: nkeywal):
bq. we just miss cache a few times more for a better perf overall?
It's difficult to be sure. But let say that if someone just removed the entry from the cache,
it makes sense to to recheck again (and to add the entry again to be cache)... I feel that
the shorter the synchronisation time the better it is, but there is nothing proven.

bq. There seems to be a bit of dodgy updating now we no longer have sync blocks. 
I think there are two things we should do:
 - removing the force delete: it's just bad imho: because someone does not want to use the
cache, it removes the entry for everybody! As well, we're doing it inside the retry loop.
That's strange.
 - when we use meta, instead of doing: ?? loc = call meta; cache(loc); return getCache()??
we should do ?? loc = call meta; cache(loc); return loc??. That's what we're doing outside
of the lock actually. It's the prefect implementation that leads us to the logic. I'm waiting
for the reverseScan before removing the prefect (this way we will do a single call instead
of two as today). But may be I should remove the prefect immediately, keeping the two calls.
The simplest implementation would just be removing all the code that is today in the lock.



> Remove some synchronisation points in HConnectionManager
> --------------------------------------------------------
>
>                 Key: HBASE-9987
>                 URL: https://issues.apache.org/jira/browse/HBASE-9987
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 0.98.0, 0.96.0
>            Reporter: Nicolas Liochon
>            Assignee: Nicolas Liochon
>             Fix For: 0.98.0, 0.96.1
>
>         Attachments: 9987.v1.patch, 9987.v2.patch
>
>
> Change a Map to a concurrentMap
> Removed the "cachedServer (introduced in HBASE-4785). I suspect that this function is
not needed anymore as we also have a list of dead servers, and accessing the list is not blocking.
I will dig into this more however.
> The patch gives a 10% improvement with the NoClusterClient.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Mime
View raw message