1

一部のWebメソッドを呼び出すときに次の例外が発生し始めたWCFサービス（SOAPベース）があります。

System.Xml.XmlException：XMLデータの読み取り中に、ネームテーブルの最大文字数クォータ（16384）を超えました。nametableは、XML処理中に検出された文字列を格納するために使用されるデータ構造です。要素名、属性名、および属性値が繰り返されない長いXMLドキュメントは、このクォータをトリガーする可能性があります。このクォータは、XMLリーダーの作成時に使用されるXmlDictionaryReaderQuotasオブジェクトのMaxNameTableCharCountプロパティを変更することで増やすことができます。1行目、4221の位置。System.Xml.XmlExceptionHelper.ThrowXmlExceptionで

サービスとクライアントの構成でクォータを増やすことでこれをすでに修正しましたが、問題が発生する前とクォータの増加を適用した後のメッセージ応答に違いは見られません。

私の質問は次のとおりです。

  1. 名前テーブルは実際にどのように機能しますか？そして、最大値を持つ名前テーブルを持つことの意味は何ですか？

  2. サービスとテストケースを変更せずにこの例外が発生し始めた理由を説明できる可能性のあるものはありますか？いくつかのメソッドを追加しましたが、それらのWebメソッドが呼び出されていなかったことを考えると、それが適切な説明であるかどうかはわかりません。

  3. 名前テーブルのデバッグに関する推奨事項はありますか？オーバーフローが発生する原因を確認してください。

ありがとう

4

2 に答える 2

1

ただし、いくつかのメソッドを追加しましたが、これらの Web メソッドが呼び出されていなかったことを考えると、それが適切な説明であるかどうかはわかりません。

プロトコルの XML メッセージの 1 つにいくつかの属性を追加しただけの WCF アプリケーションの変更に続いて、同様の動作が見られました。これらの新しい属性は少し長く (それぞれ ~25 文字以上)、長さを短くすることで問題が解消されたことが判明しました。

小さなオープン セッション メッセージで問題が発生し、エラー スタックが自動生成された XML シリアライザーを示していたことを考えると、最適化のステップとして、自動生成された XML シリアライザーは XML パーサーの名前テーブルを「コンパイルされた」XML スキーマに従って実際のサイズに一致するように、デフォルトの最大サイズの 16Kb を変更せずに最初に使用します。これは、WCF スタックがデシリアライズしようとしたときに小さな XML 要求が吹き飛ばされる理由を説明しています。

この行を追加すると、上記の問題が解決されました。

webHttpBinding.ReaderQuotas.MaxNameTableCharCount = 32768;
于 2013-12-29T22:38:43.950 に答える
1

  1. xml を解析すると、メッセージ内の各要素/属性名がテーブルに配置されるため、効率的に再利用できます。このクォータの理由は、dos (サービス拒否攻撃) を回避するためです。たとえば、誰かが非常に大きなメッセージを送信して、サーバー処理コードをすべて消費します。これが起こらないと思われる場合は、最大値を使用できます。

  2. おそらく wcf バージョンを変更したため、デフォルトが変更されました。また、何かが原因でクライアントが別の方法でシリアル化を行う (たとえば、より多くの属性) ため、より詳細なものが送信された可能性があります。

  3. クォータを増やして忘れてください..これをデバッグしたくない

于 2012-05-22T11:58:20.240 に答える