[
https://issues.apache.org/jira/browse/ROCKETMQ-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15871385#comment-15871385
]
ASF GitHub Bot commented on ROCKETMQ-98:
----------------------------------------
Github user lizhanhui commented on a diff in the pull request:
https://github.com/apache/incubator-rocketmq/pull/61#discussion_r101704927
--- Diff: common/src/main/java/org/apache/rocketmq/common/BrokerConfig.java
---
@@ -47,6 +47,7 @@
private boolean autoCreateSubscriptionGroup = true;
private String messageStorePlugIn = "";
+ //thread counts for sending message, if large number threads are
needed, we suggest setting useReentrantLockWhenPutMessage=true(in
MessageStoreConfig)
--- End diff --
IMO, this is the tradeoff between two kinds of synchronization
implementations: busy-waiting and mutex-lock; The former approach indeed wastes
more CPU cycles which may be utilized to finish other tasks by scheduler, but
it has its benefits too--doing so actually prioritize current data flow; Even
if the latter is energy-saving, it has its cons, say, more latencies are
introduced.
Another factor is the operation system being used. OS is getting so smart
that things may have changed considerably.
If someone may provide raw data, comparing effects of these two choices
under various conditions(# of cpu cores, # of send-message-threads,
flush-disk-type, etc), it would be very informative and valuable.
> Risk of unable to release putMessage Lock forever
> -------------------------------------------------
>
> Key: ROCKETMQ-98
> URL: https://issues.apache.org/jira/browse/ROCKETMQ-98
> Project: Apache RocketMQ
> Issue Type: Bug
> Affects Versions: 4.1.0-incubating
> Reporter: Jaskey Lam
> Assignee: vongosling
> Fix For: 4.1.0-incubating
>
>
> In current implemenation, there are two kind of locks dev can choose. If I
> choose reentrantLock, and lock it then put message, in this time I change the
> config through admin interface to use spin lock. When trying to unlock,
> rocketmq will try to unlock the spin lock though actually the reentrantlock
> is locked, this will cause the reentrantlock not able to release forever and
> trying to release the wrong spin lock but actully it is not locked!
> /**
> * Spin util acquired the lock.
> */
> private void lockForPutMessage() {
> if
> (this.defaultMessageStore.getMessageStoreConfig().isUseReentrantLockWhenPutMessage())
> {
> putMessageNormalLock.lock();
> } else {
> boolean flag;
> do {
> flag = this.putMessageSpinLock.compareAndSet(true, false);
> }
> while (!flag);
> }
> }
> private void releasePutMessageLock() {
> if
> (this.defaultMessageStore.getMessageStoreConfig().isUseReentrantLockWhenPutMessage())
> {
> putMessageNormalLock.unlock();
> } else {
> this.putMessageSpinLock.compareAndSet(false, true);
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
