.net 4.6.1を.net 4.6.2に更新する際に危険なものは何ですか？ アップグレードプロセスでは、重大な問題を回避するためにリリースノートを読むのにマイナーバージョンで十分だと思いました。 しかし、判明したように、Microsoftはリリースノートにいくつかの非常に興味深い面白い変更を加えることができます。
カットの下には、更新とそれを解決する方法によって生じた1つの問題の説明と、いくつかの.netソースがあります。
どうして始まったの？
スタッフ更新.net。 なんで？ はい、単純に。 「動作する-触らない」というトピックについては長い間議論できますが、アクティブなプロジェクトでは、少なくとも定期的にスタックのコンポーネントを更新する必要があると思います。 そうでなければ、ある時点で、数十のバージョンの後の更新は、コミュニティが数年前に処理した問題を更新してすくい取ろうとするよりも古いバージョンを永久にフリーズする方が簡単な痛みに変わり、誰も彼らが何を処理しなければならないか覚えていません。
一般的に、計画された更新は.net 4.7にあるはずでしたが、マイクロソフトは6か月間非常に友好的であり、パートナーシップシステムを再構築しており、現在の状況では通常どおりに拡張する方法を提供できないため、VS 2017はまだ登場していません。 そのため、少なくとも4.6.2までのバージョンに追いつくことが一時的に決定されました。
すぐに言ってやった。 更新され、テスト回路で展開され、テストされ、そして戦場で。 フライトは正常です。
問題
System.Web.HttpException（0x80004005）：セッションの要求キューの制限を超えています。
えっと、ワット？ 最も一般的なエラーを毎日分析した結果、わずかに負荷がかかったサーバーで600以上のエラーが見つかりました。 さあ、掘り始めましょう。
同時に、モバイルデバイスでhttp / 2サポートが有効になり、古いモバイルasmxサービスがスタックに表示されたため、トレースが少し混乱しました。 ありふれたリクエストが頻繁に来始め、これがキューをオーバーロードしたという疑いがありました。
asmx
はい、webApi2にはすべてが揃っているわけではありません。以前のように、プロジェクトのサイズのために徐々に移行するasmxサービスは多数あります。
このケースの練習を始めました。 セッションを含むすべてのモバイルサービスが読み取り専用で機能したため、セッションを適切なモードに転送します。
Global.asax：
if (< >) { Context.SetSessionStateBehavior(SessionStateBehavior.ReadOnly); }
回線を更新します。 モバイルデバイスの問題はなくなります。 しかし、それらはWebから使用される別のasmxサービスで発生します。
これは、主要な仮定が間違った方向に導く可能性が最も高いという疑念につながります。
Googleが助けになります！
www.google.com/search?q=The+request+queue+limit+of+the+session+is+exceeded
何が見えますか？ requestQueueLimit（サーバーへのキューのサイズ）を増やすことをお勧めします-意味がありません。 そして、どういうわけか、この制限を突破できる負荷のようには見えません。
2番目のリンク-キューに問題がある場合-「キューに触れないで、リソースを増やしてください！」
これ以上の情報はありません。 さて、もう1つの実証済みの方法が残っています。 ソース。
ソースを開いてくれたMSに本当に感謝しています。 そうでなければ、多くの問題が経験的に10倍長く解決されるか、未解決のままになっている可能性があります。 （Resharperはソースコードを移動するのにも非常に便利です）。
入力データ：
System.Web.HttpException（0x80004005）：セッションの要求キューの制限を超えています。
System.Web.SessionState.SessionStateModule.QueueRef（）で
System.Web.SessionState.SessionStateModule.PollLockedSession（）で
System.Web.SessionState.SessionStateModule.GetSessionStateItem（）で
System.Web.SessionState.SessionStateModule.BeginAcquireState（オブジェクトソース、EventArgs e、AsyncCallback cb、オブジェクトextraData）
チェーン全体を調べます。 一般的に、非常に疑わしいものはありません。 最終メソッドに到達します。
private void QueueRef() { if (!IsRequestQueueEnabled || _rqId == null) { return; } // // Check the limit int count = 0; s_queuedRequestsNumPerSession.TryGetValue(_rqId, out count); if (count >= AppSettings.RequestQueueLimitPerSession) { throw new HttpException(SR.GetString(SR.Request_Queue_Limit_Per_Session_Exceeded)); } // // Add ref s_queuedRequestsNumPerSession.AddOrUpdate(_rqId, 1, (key, value) => value + 1); }
うん そして、.NET 4.7でのみ何らかの理由で言及されているRequestQueueLimitPerSessionはどのような設定ですか？ただし、.net 3.5までの修正で広がりますか？
AppSettings.csの設定を検討します。 ビンゴ！
internal const int UnlimitedRequestsPerSession = Int32.MaxValue; internal const int DefaultRequestQueueLimitPerSession = 50; if (settings == null || !int.TryParse(settings["aspnet:RequestQueueLimitPerSession"], out _requestQueueLimitPerSession) || _requestQueueLimitPerSession < 0) _requestQueueLimitPerSession = BinaryCompatibility.Current.TargetsAtLeastFramework463 ? DefaultRequestQueueLimitPerSession : UnlimitedRequestsPerSession;
.net 4.6.3（ 明らかにシステム名は4.6.2）以前のバージョンを使用している場合、各ユーザーのキューの長さは50のリクエストによってカットされます。 制限を増やし、塗りつぶし、テスト-ハッピーエンド。
ハブに関するこの記事が、同じ問題に直面している人の助けになることを願っています。 インターネットでは、この問題に関する情報を見つけることは困難です。
PS：そのような変更がリリースノートをバイパスするのは奇妙です。 どうやら、実際には4.7からの更新と修正が配布されたということです。 しかし、私の観点からすると、これは明らかな重大な変更であり、しばらくの間アプリケーションから部分的に外れました。どういうわけか、このような変更をより明確に見たいと思います。