[
https://issues.apache.org/jira/browse/HBASE-7268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13547509#comment-13547509
]
Ted Yu commented on HBASE-7268:
-------------------------------
{code}
+ * @return SeqNum, or -1 if there's no value for server name.
{code}
Looks like javadoc update was incomplete.
{code}
+ if (openSeqNum == HConstants.NO_SEQNUM) {
+ if (!r.getRegionInfo().isRootRegion()) {
+ // If we opened non-root region, we should have read some sequence
number from it.
+ LOG.error("No sequence number found when opening " +
r.getRegionNameAsString());
+ }
+ openSeqNum = 0;
{code}
Why assigning 0 as seqNum above ?
{code}
+ public long getEarliestMemstoreSeqNum(byte[] encodedRegionName) {
+ cacheFlushLock.lock();
+ try {
+ Long result = lastSeqWritten.get(encodedRegionName);
{code}
lastSeqWritten is ConcurrentSkipListMap, do we need the lock ?
> correct local region location cache information can be overwritten w/stale
> information from an old server
> ---------------------------------------------------------------------------------------------------------
>
> Key: HBASE-7268
> URL: https://issues.apache.org/jira/browse/HBASE-7268
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.96.0
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Minor
> Fix For: 0.96.0
>
> Attachments: HBASE-7268-v0.patch, HBASE-7268-v0.patch,
> HBASE-7268-v1.patch, HBASE-7268-v2.patch, HBASE-7268-v2-plus-masterTs.patch,
> HBASE-7268-v2-plus-masterTs.patch, HBASE-7268-v3.patch
>
>
> Discovered via HBASE-7250; related to HBASE-5877.
> Test is writing from multiple threads.
> Server A has region R; client knows that.
> R gets moved from A to server B.
> B gets killed.
> R gets moved by master to server C.
> ~15 seconds later, client tries to write to it (on A?).
> Multiple client threads report from RegionMoved exception processing logic "R
> moved from C to B", even though such transition never happened (neither in
> nor before the sequence described below). Not quite sure how the client
> learned of the transition to C, I assume it's from meta from some other
> thread...
> Then, put fails (it may fail due to accumulated errors that are not logged,
> which I am investigating... but the bogus cache update is there
> nonwithstanding).
> I have a patch but not sure if it works, test still fails locally for yet
> unknown reason.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
