2012 NetSuite Web サービス (およびおそらく他のすべてのバージョン) では、.NET 2.0 64 ビット アプリケーションから呼び出しを行うと、応答がすぐに返されない場合、断続的にアプリケーションがハングすることに気付きました。 NetSuite アプリケーションは、SOAP 呼び出しが成功したようにログに記録します。ハングは最終的に 5 分 (!) 後にタイムアウト (タイムアウト) します。これは、NetSuite (または何か) がソケットを開いたままにし、パケットの送信を停止するだけだからです。
ネットワーク トレースを実行したところ、パケットの順序が乱れている、ドロップされている、不可解な重複 ACK などがあることに気付きました。マイクロソフトの技術者は、そのようなものを見たことがありません。少なくとも私が話したものはそうではありません。
パスポートを入力するだけの簡単なテスト アプリを実行し、会計期間のクエリを実行しました。SOAP 応答を解析しているときにハングするのは検索メソッドです。常に約 10 秒かかります。
32 ビット環境をターゲットにするとすぐに、32 ビット バイナリが 64 ビット OS で実行されていても、すべてが魅力的に機能します。明らかに、64 ビット アプリとして実行すると、NetSuite が実際に好まないネットワーク プロトコル構成が設定されます。
Azure、Amazon、およびローカル (社内ネットワーク) の Windows 2008 R2 SP1 64 ビット サーバー (物理および VM) でテストしました。
これが「なぜ」起こっているのかについて確固たる証拠はありませんが、1か月間髪を抜いた後（私たちは今では全員ハゲです）、問題に遭遇したと思います. これは非常に奇妙ですが、私は外に出て、それがまだ私たちが行っていることではないと主張するつもりはありません. 信じられない場合は、次のようにします。
Visual Studio 2010 を開き、「任意の CPU」を対象とする .NET 2.0 コンソール アプリケーションを作成します。
「Web 参照の追加...」を実行し、NetSuite WSDL を追加します。
単純なパスポート ログインを作成し、検索を実行して、ある程度ボリュームのあるものを返します。
EXE を 64 ビット OS で数回実行します (このバグは断続的です)。作業時間のピーク時 (太平洋標準時の午前 7 時から午後 2 時頃に表示されます)。
それがまさに私たちがしたことです。戻って新しい x86 ターゲットを作成し、プロジェクトを再構築すると、問題なく動作します。