仍然沿用Corda Services的趨勢，我還有其他一些技巧可幫助您的CorDapp順利工作。 這次，我們將重點(diǎn)關(guān)注使用trackBy從服務(wù)內(nèi)部啟動(dòng)流以及如果您不小心可能會(huì)引起的離散問題。

這應(yīng)該是一個(gè)相對(duì)簡短的職位，因?yàn)槲铱梢砸揽恐暗穆毼?#xff1a; Corda Services 101和Corda Services的 異步流程調(diào)用 。 在Corda Services的“異步流”調(diào)用中找到的內(nèi)容與此帖子非常相關(guān)，并且將包含此帖子中未包含的其他信息。

這篇文章適用于Corda Open Source和Enterprise。 撰寫本文時(shí)的版本為Open Source 3.2和Enterprise 3.1 。

trackBy簡介

trackBy允許您編寫在包含指定類型的狀態(tài)的事務(wù)完成時(shí)執(zhí)行的代碼。 無論將它們作為輸入還是輸出，代碼仍將觸發(fā)。

在這里，您可以決定要執(zhí)行的操作。 也許很簡單，例如記錄已收到狀態(tài)的日志。 或者，也許更有趣的事情，例如啟動(dòng)新流程。 此用例對(duì)該功能非常有意義。 節(jié)點(diǎn)接收到新狀態(tài)或消耗新狀態(tài)后，便可以啟動(dòng)代表流程中下一個(gè)邏輯步驟的新流程。

此外，還有trackBy兩個(gè)版本。 一是我一直提到的trackBy ，可以在CorDapp中使用。 另一個(gè)vaultTrackBy是使用RPC從節(jié)點(diǎn)外部調(diào)用的。

本文中提出的問題僅在CorDapp版本trackBy 。 因此，在本文的其余部分中，我們將不包括vaultTrackBy 。

這個(gè)離散的問題是什么？

僵局。 當(dāng)我這樣說時(shí)，它不是很離散。 但是，它的發(fā)生方式相當(dāng)微妙，需要對(duì)將要解決的問題有一個(gè)很好的了解。 如前所述，此問題與Corda Services的異步流調(diào)用中詳細(xì)介紹的問題非常相似。 此外，當(dāng)我在項(xiàng)目中遇到此問題時(shí)，R3再次大喊大叫以診斷此問題，我確信他們會(huì)解決這個(gè)問題。 在此之前，如果您遇到相同的問題，這篇文章應(yīng)該可以省去一些麻煩。

我將引用我在上一篇文章中寫的內(nèi)容，因?yàn)樗慕忉寖H缺少關(guān)于該帖子的一點(diǎn)。

“ Flow Worker隊(duì)列負(fù)責(zé)執(zhí)行Flow執(zhí)行的順序，并在Flow添加和完成時(shí)填充并為空。 該隊(duì)列對(duì)于協(xié)調(diào)節(jié)點(diǎn)內(nèi)流的執(zhí)行至關(guān)重要。 當(dāng)涉及到多線程Flows本身時(shí)，這也是痛苦的根源。”

“我為什么要談?wù)撨@個(gè)隊(duì)列？ 好吧，我們需要格外小心，不要將無法完成的流程填滿隊(duì)列。

怎么會(huì)這樣 通過在正在執(zhí)行的流程中啟動(dòng)流程，然后流程等待其完成。 直到隊(duì)列的線程池中的所有線程都遇到這種情況，這才不會(huì)引起問題。 一旦發(fā)生，它將使隊(duì)列陷入僵局。 沒有流程可以完成，因?yàn)樗鼈兌家蕾囉谂抨?duì)的多個(gè)流程來完成。”

那標(biāo)志著我的復(fù)制面的終結(jié)。 我會(huì)繼續(xù)說這句話，實(shí)際上，我建議您通讀Corda Services的異步流調(diào)用，以對(duì)該主題進(jìn)行徹底的解釋。

這與trackBy有什么關(guān)系？ 從服務(wù)調(diào)用trackBy將在Flow Worker線程上運(yùn)行每個(gè)可觀察的事件。 換句話說，每個(gè)事件都占據(jù)隊(duì)列中的一個(gè)位置。 從此處啟動(dòng)Flow將向隊(duì)列添加另一個(gè)項(xiàng)目，并掛起當(dāng)前線程，直到Flow完成。 它將一直保留在隊(duì)列中，直到那個(gè)時(shí)候。 如果您遇到的情況是隊(duì)列中的所有位置都由可觀察的事件而不是實(shí)際的流程所占據(jù)，那么我為您提供了一個(gè)詞。 僵局。 這與我之前詳細(xì)介紹過的情況完全相同，只是從不同的震中開始。

從好的方面來說，解決方案是小菜一碟（這句話從何而來？）。

解決問題的部分

現(xiàn)在您知道了問題所在。 將“中斷”版本更改為可避免死鎖的版本，僅需要幾行。

讓我們看一些與導(dǎo)致我踏上這個(gè)地雷的代碼非常相似的代碼：

每當(dāng)節(jié)點(diǎn)收到新的MessageState時(shí)，此Service就會(huì)使用trackBy啟動(dòng)新的Flow。 由于前面提到的所有原因，此代碼可能會(huì)死鎖。 我們不知道什么時(shí)候發(fā)生，或者是否會(huì)發(fā)生。 但是，可以。 因此，我們可能應(yīng)該在問題解決之前對(duì)其進(jìn)行整理。

下面的代碼將做到這一點(diǎn)：

我添加了一些注釋以使更改更清晰，因?yàn)閮H添加了幾行。

所有這些更改所做的就是在新線程上啟動(dòng)Flow。 然后，這將允許當(dāng)前線程結(jié)束。 請(qǐng)記住，這很重要，因?yàn)樵摼€程保持在隊(duì)列中的某個(gè)位置。 允許它結(jié)束，為接下來發(fā)生的事情騰出空間。 它是來自trackBy還是Flow的另一個(gè)可觀察事件。 不要緊。 只要釋放線程，就不會(huì)由于該代碼而發(fā)生死鎖。

從此線程釋放您

請(qǐng)花一點(diǎn)時(shí)間來欣賞我在本節(jié)標(biāo)題中所做的雙關(guān)語的榮耀。 也許不是很好，但我仍然為此感到自豪。

總之，在Corda Service中使用trackBy非常適合根據(jù)已保存到節(jié)點(diǎn)的信息來啟動(dòng)新流程。 但是，從trackBy觀察開始新流程時(shí)，您需要小心。 這是由于可觀察到的保持在Flow Worker線程上，因此是隊(duì)列中的一個(gè)點(diǎn)。 如果吞吐量達(dá)到更高的數(shù)量，則可能會(huì)出現(xiàn)節(jié)點(diǎn)死鎖的風(fēng)險(xiǎn)。 您可能會(huì)遇到以下情況：隊(duì)列被所有線程都阻塞，這些線程都在等待流完成，但隊(duì)列中沒有實(shí)際的流。 通過將Flow調(diào)用移動(dòng)到與可觀察線程不同的線程上。 您可以釋放隊(duì)列中曾經(jīng)保留的位置。 現(xiàn)在，您的trackBy代碼不再可能導(dǎo)致死鎖。

這篇文章中使用的代碼可以在我的GitHub上找到 。

如果您認(rèn)為這篇文章有幫助，可以在Twitter上@LankyDanDev關(guān)注我，以跟上我的新文章。

翻譯自: https://www.javacodegeeks.com/2018/10/starting-flows-trackby.html

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的使用trackBy启动流程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。