[
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)
