[
https://issues.apache.org/jira/browse/ROCKETMQ-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16362055#comment-16362055
]
ASF GitHub Bot commented on ROCKETMQ-332:
-----------------------------------------
coveralls commented on issue #227: [ROCKETMQ-332] fix concurrent bug in
MappedFileQueue#findMappedFileByOffset, which m…
URL: https://github.com/apache/rocketmq/pull/227#issuecomment-365181234
[](https://coveralls.io/builds/15499533)
Coverage increased (+0.02%) to 40.062% when pulling
**a0e5c810fe14304cc1a3ff3065e14c18d8adbfa8 on Jason918:ROCKETMQ-332** into
**285c780602f58af65d5253c33585699d9a688d86 on apache:master**.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> MappedFileQueue is not thread safe, which will cause message loss.
> ------------------------------------------------------------------
>
> Key: ROCKETMQ-332
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-332
> Project: Apache RocketMQ
> Issue Type: Bug
> Components: rocketmq-store
> Affects Versions: 4.0.0-incubating, 4.1.0-incubating
> Reporter: Jas0n918
> Assignee: yukon
> Priority: Major
> Attachments: rocketmq.log
>
>
> In RocketMQ V3.5.8, there is a readWriteLock in
> com.alibaba.rocketmq.store.MapedFileQueue, which guarantee thread safety. But
> in the new org.apache.rocketmq.store.MappedFileQueue, there is not any
> concurrent control mechanism.
> when consumer is fetching message(no large lag), broker calls
> org.apache.rocketmq.broker.processor.PullMessageProcessor#processRequest ==>
> org.apache.rocketmq.store.DefaultMessageStore#getMessage ==>
> org.apache.rocketmq.store.ConsumeQueue#getIndexBuffer ==>
> org.apache.rocketmq.store.MappedFileQueue#findMappedFileByOffset
> but findMappedFileByOffset is not thread safe, as
> org.apache.rocketmq.store.MappedFileQueue#deleteExpiredFile maybe running
> concurrently( the size of mappedFiles maybe change) , which will results in
> ConsumeQueue#getIndexBuffer returns null, causing
> _nextBeginOffset = nextOffsetCorrection(offset,
> consumeQueue.rollNextFile(offset));_+
> which will skip the whole consumeQueue file, any messages left in this
> ConsumeQueue will not be consumed by client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
