[
https://issues.apache.org/jira/browse/ROCKETMQ-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880379#comment-15880379
]
ASF GitHub Bot commented on ROCKETMQ-107:
-----------------------------------------
Github user Jaskey commented on the issue:
https://github.com/apache/incubator-rocketmq/pull/68
@Ah39
The problem is not only the synchrinaztion on state's read/write, but on
`shutdown` and `start` , `shutdown` and `start` should be syncronized
For example, two thread may start in the same time and the the resources
will be initized twice, actually the later one should be rejected, which is the
problem I issue.
> Access ServiceState is not thread safe when start() or shutdown()
> -----------------------------------------------------------------
>
> Key: ROCKETMQ-107
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-107
> Project: Apache RocketMQ
> Issue Type: Bug
> Components: rocketmq-client
> Reporter: Jaskey Lam
> Assignee: Jaskey Lam
> Priority: Minor
>
> When start() or shutdown(), service's state is not thread safe which may
> break happen-before.
> For example:
> switch (this.serviceState) {
> case CREATE_JUST:
> log.info("the consumer [{}] start beginning. messageModel={},
> isUnitMode={}", this.defaultMQPushConsumer.getConsumerGroup(),
> this.defaultMQPushConsumer.getMessageModel(),
> this.defaultMQPushConsumer.isUnitMode());
> this.serviceState = ServiceState.START_FAILED;
> ..// do some start job here
> this.serviceState = ServiceState.RUNNING;
> break;
> case RUNNING:
> case START_FAILED:
> case SHUTDOWN_ALREADY:
> throw new MQClientException("The PushConsumer service state
> not OK, maybe started once, "//
> + this.serviceState//
> + FAQUrl.suggestTodo(FAQUrl.CLIENT_SERVICE_NOT_OK),
> null);
> default:
> break;
> }
> 1. If the user is start twice in two thread, the resources may initize twice.
> 2. if the user start in threadA and shutdown very quicky in another thread B,
> shutdown may not reclaim the resources.
> Though the sceniro is very uncommon, but it is indeed a bug here. Fix is
> actually quite trivial.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
