Hi, Tom This's really a problem if it causes deadlock but, which might not be true, I think doing cancommit sequentially rather than concurrently may bring huge performance degradation in some cases. Thanks a lot for the details provided.
All the best Hangyu -----原始邮件----- 发件人: "Tom Pantelis" <tompante...@gmail.com> 发送时间: 2016-10-24 08:54:44 (星期一) 收件人: Hangyu <fh...@mails.tsinghua.edu.cn> 抄送: controller-dev <controller-dev@lists.opendaylight.org>, nx...@126.com, liyon...@tsinghua.edu.cn 主题: Re: [controller-dev] Is it possible to parallel proceed can-commit in three-phase-commit of datastore They used to be issued in parallel but it caused deadlock - see https://bugs.opendaylight.org/show_bug.cgi?id=2792 On Sun, Oct 23, 2016 at 5:56 AM, Hangyu <fh...@mails.tsinghua.edu.cn> wrote: Hi guys, I've found that while submitting data that located in multiple shards to datastore, the ThreePhaseCommitCohortProxy asks each ShardCoordinator by sending can-commit message(RPC) One-By-One. So I wonder what if these can-commit messages were sent parallel? Is there any side-effect to do this? The source code is located in controller/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/datastore/ThreePhaseCommitCohortProxy.java, line 156-199, and you can read it here. Thanks for answering in advance. private void finishCanCommit(final SettableFuture<Boolean> returnFuture) { LOG.debug("Tx {} finishCanCommit", transactionId); // For empty transactions return immediately if (cohorts.size() == 0) { LOG.debug("Tx {}: canCommit returning result true", transactionId); returnFuture.set(Boolean.TRUE); return; } commitOperationCallback = new TransactionRateLimitingCallback(actorContext); commitOperationCallback.run(); final Iterator<CohortInfo> iterator = cohorts.iterator(); final OnComplete<Object> onComplete = new OnComplete<O bject>() { @Override public void onComplete(Throwable failure, Object response) { if (failure != null) { LOG.debug("Tx {}: a canCommit cohort Future failed", transactionId, failure); returnFuture.setException(failure); commitOperationCallback.failure(); return; } // Only the first call to pause takes effect - subsequent calls before resume are no-ops. So // this means we'll only time the first transaction canCommit which should be fine. commitOperationCallback.pause(); boolean result = true; if (CanCommitTransactionReply.isSerializedType(response)) { CanCommitTransactionReply reply = CanCommitTransactionReply.fromSerializable(response); LOG.debug("Tx {}: received {}", transactionId, response); if (!reply.getCanCommit()) { &nbs p; result = false; } } else { LOG.error("Unexpected response type {}", response.getClass()); returnFuture.setException(new IllegalArgumentException( String.format("Unexpected response type %s", response.getClass()))); return; } if (iterator.hasNext() && result) { &nb sp; sendCanCommitTransaction(iterator.next(), this); } else { LOG.debug("Tx {}: canCommit returning result: {}", transactionId, result); returnFuture.set(Boolean.valueOf(result)); } } }; sendCanCommitTransaction(iterator.next(), onComplete); } -- Fan Hangyu Department of Electronic Engineering, Tsinghua University, Beijing 100084, P. R. China Email: fh...@mails.tsinghua.edu.cn _______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev -- Fan Hangyu Department of Electronic Engineering, Tsinghua University, Beijing 100084, P. R. China Email: fh...@mails.tsinghua.edu.cn
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
