国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

謠言粉碎機(jī) - 極短時(shí)間內(nèi)發(fā)送兩個(gè)Odata request，前一個(gè)會(huì)自動(dòng)被cancel掉?

RichardXG / 2741人閱讀

摘要：背景有時(shí)我們能在開發(fā)者工具的里觀察到應(yīng)用會(huì)發(fā)出某些狀態(tài)為取消的請(qǐng)求。如下圖第五個(gè)請(qǐng)求。之前有一種似是而非的說法極短時(shí)間內(nèi)發(fā)送兩個(gè)請(qǐng)求，則第一個(gè)會(huì)自動(dòng)被掉。前一個(gè)請(qǐng)求的還處于的時(shí)候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時(shí)候。

背景

有時(shí)我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會(huì)發(fā)出某些狀態(tài)為"取消"的OData請(qǐng)求。如下圖第五個(gè)請(qǐng)求。

之前有一種似是而非的說法:極短時(shí)間內(nèi)發(fā)送兩個(gè)OData請(qǐng)求，則第一個(gè)會(huì)自動(dòng)被cancel掉。

這個(gè)說法從字面上看，有兩點(diǎn)值得推敲:

1. cancel掉，被誰cancel掉？UI5框架還是Chrome？

2. “極短”，多短算極短？

我用代碼在for循環(huán)里一共發(fā)10個(gè)OData請(qǐng)求：

無論是同步還是異步，都沒有任何的請(qǐng)求被cancel。

10個(gè)同步請(qǐng)求：

10個(gè)異步請(qǐng)求：

就算發(fā)100個(gè)request都不會(huì)有一個(gè)request被cancel:

驗(yàn)證結(jié)果，之前的說法“極短時(shí)間內(nèi)發(fā)送兩個(gè)OData request，前一個(gè)會(huì)自動(dòng)被cancel掉”是錯(cuò)誤的。

那再回到本文第一張圖觀察到的cancel的場(chǎng)景, 原因究竟是什么？

觀察產(chǎn)生了被取消的OData請(qǐng)求的應(yīng)用代碼，觀察到第523行有這個(gè)refresh操作：

在這個(gè)方法的第601行，bChangeDetected變量為true導(dǎo)致abortPendingRequest的調(diào)用。

abortPendingRequest的注釋已經(jīng)很清楚地說明問題了。

什么情況下會(huì)導(dǎo)致AbortPendingRequest? 直接使用Chrome開發(fā)者工具的全文搜索得到答案：OData model的三個(gè)API: filter, sort, refresh

下面是我的同事Li Ben的進(jìn)一步補(bǔ)充。

關(guān)于這個(gè)現(xiàn)象發(fā)生的原因和條件的問題

1. 在哪里可以看到這個(gè)cancel現(xiàn)象?

在我們的live search功能上，如果輸入較快或者正常速度輸入，會(huì)看到前面很多輸入請(qǐng)求都會(huì)被cancel掉:

如果輸入較慢則不會(huì):

真的是快慢的原因嗎？

仔細(xì)觀察network發(fā)現(xiàn)，真正的原因是當(dāng)上一次的network還處于pending狀態(tài)的時(shí)候，繼續(xù)輸入發(fā)起的請(qǐng)求就會(huì)cancel掉上一次的請(qǐng)求:

繼續(xù)深究， 這是在哪里做到的？

在SAP UI5的OData框架里面有這樣的實(shí)現(xiàn):

在ODataModel.js中維護(hù)了一個(gè)http request的pending list，將已經(jīng)發(fā)送但是還沒有收到響應(yīng)的request對(duì)象都緩存在這個(gè)列表中:

每次發(fā)起OData請(qǐng)求的時(shí)候都會(huì)調(diào)用ODataModel的_request()方法，這個(gè)方法會(huì)把當(dāng)前的request加到pending list中，并且通過一個(gè)wrap method包裝回調(diào)函數(shù)，確保在響應(yīng)返回的時(shí)候首先把緩存的request對(duì)象從pending list中拿掉:

每次在OData Model上發(fā)起filter, sort, refresh操作的時(shí)候，都會(huì)檢查是否存在pending的request對(duì)象，如果存在未完成的請(qǐng)求，abort掉它:

回答上面的問題，在什么情況下會(huì)發(fā)生這種現(xiàn)象?

1. 同一個(gè)ODataModel的instance上發(fā)出的連續(xù)請(qǐng)求，因?yàn)閜ending list是緩存在this級(jí)別上面的。

2. 前一個(gè)Http請(qǐng)求的network還處于pending status的時(shí)候。

3. 就讀ODataModel的代碼和觀察到的現(xiàn)象，在ODataModel上發(fā)起filter, sort或者refresh的時(shí)候。

為什么在OData的request對(duì)象上發(fā)起abort調(diào)用就可以取消底層的network call?

簡(jiǎn)單的說，UI5里面的OData Request對(duì)象是底層的Ajax Request對(duì)象XmlHttpRequest的一個(gè)代理，在ODataModel的_submit方法中:

具體實(shí)現(xiàn)是UI5中利用了一個(gè)第三方的庫datajs，datajs最終會(huì)調(diào)用瀏覽器的底層http對(duì)象XMLHttpRequest:

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/92926.html

相關(guān)文章

  • 謠言粉碎機(jī) - 極短時(shí)間內(nèi)發(fā)送兩個(gè)Odata request，前一個(gè)會(huì)自動(dòng)被cancel掉?

    摘要：背景有時(shí)我們能在開發(fā)者工具的里觀察到應(yīng)用會(huì)發(fā)出某些狀態(tài)為取消的請(qǐng)求。如下圖第五個(gè)請(qǐng)求。之前有一種似是而非的說法極短時(shí)間內(nèi)發(fā)送兩個(gè)請(qǐng)求，則第一個(gè)會(huì)自動(dòng)被掉。前一個(gè)請(qǐng)求的還處于的時(shí)候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時(shí)候。 背景 有時(shí)我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會(huì)發(fā)出某些狀態(tài)為取消的OData請(qǐng)求。如下圖第五個(gè)請(qǐng)求。 之前有一種似...

    you_De 評(píng)論0 收藏0

  • 謠言粉碎機(jī) - 極短時(shí)間內(nèi)發(fā)送兩個(gè)Odata request，前一個(gè)會(huì)自動(dòng)被cancel掉?

    摘要：背景有時(shí)我們能在開發(fā)者工具的里觀察到應(yīng)用會(huì)發(fā)出某些狀態(tài)為取消的請(qǐng)求。如下圖第五個(gè)請(qǐng)求。之前有一種似是而非的說法極短時(shí)間內(nèi)發(fā)送兩個(gè)請(qǐng)求，則第一個(gè)會(huì)自動(dòng)被掉。前一個(gè)請(qǐng)求的還處于的時(shí)候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時(shí)候。 背景 有時(shí)我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會(huì)發(fā)出某些狀態(tài)為取消的OData請(qǐng)求。如下圖第五個(gè)請(qǐng)求。 之前有一種似...

    ?xiaoxiao, 評(píng)論0 收藏0

  • 謠言粉碎機(jī) - 極短時(shí)間內(nèi)發(fā)送兩個(gè)Odata request，前一個(gè)會(huì)自動(dòng)被cancel掉?

    摘要：背景有時(shí)我們能在開發(fā)者工具的里觀察到應(yīng)用會(huì)發(fā)出某些狀態(tài)為取消的請(qǐng)求。如下圖第五個(gè)請(qǐng)求。之前有一種似是而非的說法極短時(shí)間內(nèi)發(fā)送兩個(gè)請(qǐng)求，則第一個(gè)會(huì)自動(dòng)被掉。前一個(gè)請(qǐng)求的還處于的時(shí)候。就讀的代碼和觀察到的現(xiàn)象，在上發(fā)起或者的時(shí)候。 背景 有時(shí)我們能在Chrome開發(fā)者工具的Network tab里觀察到SAP UI5應(yīng)用會(huì)發(fā)出某些狀態(tài)為取消的OData請(qǐng)求。如下圖第五個(gè)請(qǐng)求。 之前有一種似...

    kamushin233 評(píng)論0 收藏0

  • 為拯救爸媽朋友圈，達(dá)摩院造了“謠言粉碎機(jī)”

    摘要：達(dá)摩院的科學(xué)家們最近在用識(shí)別謠言的研究上，有了一些小突破。有始有終，皆大歡喜達(dá)摩院所研發(fā)的謠言粉碎機(jī)，在剛剛結(jié)束的全球語義測(cè)試中，創(chuàng)造了假新聞識(shí)別準(zhǔn)確率的新紀(jì)錄，達(dá)到了前所未有的。謠言粉碎機(jī)技術(shù)的背后，是一次史無前例的信任重建。 showImg(https://segmentfault.com/img/remote/1460000018343265); 生命不可能從謊言中開出燦爛的鮮花...

    levy9527 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<