問題タブ [azureservicebus]

WCF-Custom アダプターを使用して Servicebus キューに接続されている BizTalk に重大なバグがあることに気付きました (何か不足していない限り)。

メッセージがキューから BizTalk に到達していないことに気付いたので、受信場所が BizTalk で実行されていることを確認しました。

ただし、メッセージがキューに積み上げられていることがわかりました。

BizTalk は警告またはエラー メッセージを提供せず、受信場所がキューへの接続を失ったという BizTalk からの兆候もありませんでした。

受信場所を再起動すると、Servicebus 管理コンソールで messagecount がゼロになるのを確認できたので、BizTalk が気付かないうちに接続を失ったようです。

何か重要なものを見逃していない場合、これは BizTalk の非常に深刻なバグです。これは、警告や顕著な理由なしにフローをブロックするためです。

この問題に遭遇した同僚が 2 人いますが、彼らは sftp-adapter を使用していたと思います。

他の誰かがこの行動の経験がありますか?

グーグルで検索してみましたが、何も見つかりませんでした。

Azure Service Busキュー（Azureストレージキューではありません）を調べています。私が読んだすべての詳細は、FIFOセマンティクスをサポートしていることを示していますが、これは「メッセージングセッション」のコンテキストでのみです。問題は、Azureのコンテキストでこれが正確に何であるかについての情報を見つけることができないように見えることです。これはWCF構造ですか、それともAzure Service Busに固有のものですか？ローカルトランザクションとは関係ないと思いますが、100％確信はありません。

どんなポインタも非常に役に立ちます。ありがとう！

Worker ロールから Service Bus Queue にメッセージを送信しています。いくつかのメッセージがランダムに失われていることに気付きました。

デバッグするときは、Send メソッドの後にブレークポイントを設定し、Azure Panel にログインして、メッセージ キューが増加したかどうかを確認します。私が見つけたのは、奇妙なことに、メッセージがキューに追加されない場合があるということです。しかし、それはランダムではありません。パターンは次のとおりです。1 つのメッセージが正しく追加され、次のメッセージが失われ、次のメッセージは問題なく追加され、次のメッセージが失われます。

次のような再試行パターンを実装しましたが、すべてのメッセージが正しく送信されているわけではないようです。

私のコードは次のとおりです。

何が間違っている可能性がありますか？

同じ名前空間内の異なるアドレスを持つ2つの異なるリレーエンドポイントによって公開されているサービスをアクティブ化できません。それらの1つを削除すると、サービスが正常にアクティブ化されるため、構成は正常です。バインディングのタイプを変更し、名前空間を変更し、1つだけではなく2つの動作構成を追加しようとしましたが、常に同じエラーが発生します（下部）。

私が何かを逃しているかどうか誰かが知っていますか？同じ名前空間に2つのリレーエンドポイントを含めることはできますか？

エラーは次のとおりです。

ExceptionDetail。おそらくIncludeExceptionDetailInFaults=trueによって作成され、その値は次のとおりです。System.ArgumentException：コレクションに同じタイプのアイテム'Microsoft.ServiceBus.NameSettings'が既に含まれているため、値をコレクションに追加できませんでした。このコレクションは、各タイプの1つのインスタンスのみをサポートします。パラメータ名：System.Collections.Generic.KeyedByTypeCollectionのアイテム1.InsertItem(Int32 index, TItem item) at Microsoft.ServiceBus.ServiceRegistrySettings.System.ServiceModel.Description.IEndpointBehavior.AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters) at System.ServiceModel.Description.DispatcherBuilder.AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection parameters) at System.ServiceModel.Description.DispatcherBuilder.GetBindingParameters(ServiceHostBase serviceHost, Collection1エンドポイント）at System.ServiceModel.Description.ServiceMetadataBehavior.MetadataExtensionInitializer.GenerateMetadata（）at System.ServiceModel.Description.ServiceMetadataExtension.EnsureInitialized（）at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.InitializationData.InitializeFrom（ServiceMetadataExtension System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.ProcessHttpRequest（Message httpGetRequest ）at SyncInvokeGet（Object、Object []、Object []）atSystem.ServiceModel.Dispatcher.SyncMethodInvoker。System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin（MessageRpc＆rpc）at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5（MessageRpc＆rpc）at System.ServiceModel.DispatcherでInvoke（Object instance、Object [] input、Object []＆outputs） System.ServiceModel.Dispatcher.MessageRpc.Process（Boolean isOperationContextSet）の.ImmutableDispatchRuntime.ProcessMessage31（MessageRpc＆rpc）Process（ブールisOperationContextSet）Process（ブールisOperationContextSet）

AzureServiceバスで断続的な問題が発生しています。散発的に、バスにメッセージを配置すると、次の例外が発生します。

タイプ：InvalidOperationException

メッセージ：仲介されたメッセージ「723eab13dab34351a78bb687d0923b89」がすでに消費されているため、操作を実行できません。操作には新しいBrokeredMessageインスタンスを使用してください。

スタックトレース

AzureBusの問題のあるコードは次のとおりです。

渡されるTメッセージは

そして、_retryPolicyは

_timeToLiveは12時間のタイムスパンです

何か案は？

と の両方でAzure Service Bus Relayを使用しているときに、速度の問題が発生しています。小さなメッセージ サイズ ( 10K ) では、リレーは低遅延 ( 100ms ) で動作しますが、メッセージ サイズが大きくなると ( 100K )、一見ランダムな応答時間 ( 600ms-1000ms ) が発生します。大きなメッセージのレイテンシ コストを改善したいと考えています。netTcpRelayBindingbasicHttpRelayBinding

メッセージ圧縮 ( gzip、protobuf-netなど) の使用は Service Bus Relay でサポートされていますか? リレーを介してリクエスト/レスポンス圧縮の両方を有効にすることに成功した人はいますか? IIS を介して応答圧縮をサポートするのは簡単ですが、遅延コストを改善するために要求圧縮をサポートしたいと考えています。Fiddlerを使用してリレーをプロファイリングすることはできないため、メッセージがリレーを通過するときにまだ圧縮されていることをどのように知ることができるでしょうか?

私たちが発見した興味深い点は、後続のメッセージリレー間に遅延 (2 秒) を導入すると、パフォーマンスが向上する ( 100K - 200ms ) ことです。より大きなメッセージが自動的に調整されている可能性はありますか? スロットリング条件をトリガーするメッセージ サイズのカットオフを知っておくとよいでしょう。

私たちのテストでは、ランダムなメッセージ文字列をサービス リレーに送信し、サーバーから要求文字列をエコー バックするだけです。このクライアント/サーバーを複数の地理的な場所から (ファイアウォール/Web フィルターの問題を除外するために)試してみましたが、同じ遅延動作が発生しました。

サーバ側

クライアント側

新しい Windows Server Service Bus 1.0 Beta を使用して、新しいプロジェクトの作業を開始しています。AWS EC2 仮想マシンでテスト環境をセットアップしようとしています。

AWS EC2 で実行されている Windows Server 2008 R2 インスタンスに Service Bus をインストールし、MSDN ドキュメントの例に従って新しいファーム、コンテナー、およびホストをセットアップしました。サーバー上で適切なポートをすべて開いています (4443 および 9354)。また、[このページ][1] の指示に従って、自己生成証明書をクライアント マシンにエクスポートしました。

キューを作成し、メッセージをキューに入れ、それを受信する非常に単純な C# プログラムがあります。このプログラムは、実行可能ファイルを VM にコピーしてそこで実行すると正常に動作するので、API を正しく使用していると思います。ただし、AWS サーバーを指すローカル開発ボックスからプログラムを実行すると、セキュリティ例外が発生します。

私のコードは次のようになります。

私の例外トレースは次のようになります。

問題は、FQDN ではなく VM の IP アドレスを使用して接続していることだと思いますが、それを確認する方法も、AWS サーバーのドメイン名を取得する方法もわかりません。サーバーにはマシン名がありますが、ドメインではなく、単にワークグループ「WORKGROUP」にあります。

ありとあらゆる助けをいただければ幸いです。

WebRole と 2 つの ServiceBus WorkerRoles を実行しています。ロールの OnStart 中に次の例外が発生します: [System.ArgumentOutOfRangeException] コンテナ log4net の無効な構文 パラメータ名: initialConfiguration

これは、開発 Azure 環境とクラウドでローカルに実行しているときに発生します。すべての役割には、次の構成設定があります。

すべてのロールには、OnStart に次のコードがあります。

スタックトレース：

Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorConfiguration.Validate(String paramName, Nullable`1 resourceSize) Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitor.StartWithExplicitConfiguration(DiagnosticMonitorStartupInfo startupInfo, DiagnosticMonitorConfiguration initialConfiguration) Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitor.Start(CloudStorageAccount storageAccount, c:\Projects\Client\Connection Intelegence\CICloud\CICRMIntegrationQueue\WorkerRole.cs:line 193 の CICRMIntegrationQueue.WorkerRole.OnStart() の Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitor.Start(String diagnosticsStorageAccountConfigurationSettingName, DiagnosticMonitorConfiguration initialConfiguration) の DiagnosticMonitorConfiguration initialConfiguration)

このエラーは、3 つのロールすべてでローカル ストレージとDiagnosticMonitorポーリングを使用している場合に発生するようですが、1 つだけが定義されている場合、エラーは発生しません。

Azure Service Bus 名前空間には、SubscriptionClient次の方法で MessageSession を開始するメソッドを持つ型があります。

これは同期バージョンで、MessageSession を返します。このライブラリは、非同期バージョンの BeginAcceptMessageSession() も提供します。これは、コールバックを呼び出し、IAsyncResult と渡したい状態オブジェクトを渡すため、つまずきます。私の場合、SubscriptionClient インスタンスを渡しているので、SubscriptionClient で EndAcceptMessageSession() を呼び出すことができます。BeginAcceptMessageSession() の戻り値の型は void です。

BeginAcceptMessageSession() を介して受け入れられる MessageSession にアクセスするにはどうすればよいですか? コールバックの結果パラメーターに返されるのは、EndAcceptMessageSession() を介して BeginAcceptMessageSession() を終了するために必要な SubscriptionClient インスタンスだけです。

MessageSession リファレンスはどこにもありません。この点に関して、ドキュメントは役に立ちません。Google で検索してもわずか 3 ページの検索結果しか表示されません。そのほとんどは、MSDN からのメソッド自体のオンライン説明にすぎません。AsyncManager.Parameters を調べましたが、これも空です。

このように作成された MessageSession への参照を取得できるように、BeginAcceptMessageSession() を呼び出す方法を知っている人はいますか?