[
https://issues.apache.org/jira/browse/HBASE-21564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16713229#comment-16713229
]
Sergey Shelukhin commented on HBASE-21564:
------------------------------------------
[~stack] yes, I've seen in in the logs, also it follows from current logic (see
how the WAL->bool map is used, it's only used for setting the force flag.
{noformat}
2018-11-21 21:19:46,064 INFO [regionserver/...:17020.logRoller]
wal.AbstractFSWAL: Rolled WAL
<...>%2C17020%2C1542754626176.meta.1542863983299.meta with entries=2,
filesize=1.39 KB; new WAL <...>%2C17020%2C1542754626176.meta.1542863986017.meta
2018-11-21 21:19:46,096 INFO [regionserver/...:17020.logRoller]
wal.AbstractFSWAL: Rolled WAL <...>%2C17020%2C1542754626176.1542863983330 with
entries=1007, filesize=132.38 MB; new WAL
<...>%2C17020%2C1542754626176.1542863986064
2018-11-21 21:19:56,299 INFO [regionserver/...:17020.logRoller]
wal.AbstractFSWAL: Rolled WAL
<...>%2C17020%2C1542754626176.meta.1542863991299.meta with entries=1,
filesize=754 B; new WAL <...>%2C17020%2C1542754626176.meta.1542863996267.meta
2018-11-21 21:19:56,314 INFO [regionserver/...:17020.logRoller]
wal.AbstractFSWAL: Rolled WAL <...>%2C17020%2C1542754626176.1542863993877 with
entries=965, filesize=130.57 MB; new WAL
<...>%2C17020%2C1542754626176.1542863996299
{noformat}
etc.
It's basically rolling meta WAL with other WALs as long as there's anything at
all in it.
I think it will mostly be relevant if someone uses multi-wal, as it will roll a
whole bunch of different WALs.
Test failures look related.
I will change the semantics to only roll the requisite WALs and look at test
failures.
> race condition in WAL rolling resulting in size-based rolling getting stuck
> ---------------------------------------------------------------------------
>
> Key: HBASE-21564
> URL: https://issues.apache.org/jira/browse/HBASE-21564
> Project: HBase
> Issue Type: Bug
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Priority: Major
> Attachments: HBASE-21564.master.001.patch
>
>
> Manifests at least with AsyncFsWriter.
> There's a window after LogRoller replaces the writer in the WAL, but before
> it sets the rollLog boolean to false in the finally, where the WAL class can
> request another log roll (it can happen in particular when the logs are
> getting archived in the LogRoller thread, and there's high write volume
> causing the logs to roll quickly).
> LogRoller will blindly reset the rollLog flag in finally and "forget" about
> this request.
> AsyncWAL in turn never requests it again because its own rollRequested field
> is set and it expects a callback. Logs don't get rolled until a periodic roll
> is triggered after that.
> The acknowledgment of roll requests by LogRoller should be atomic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
