問題タブ [resiliency]

• Installshield 2008 によって作成された MSI ファイルが「自己修復」によって再インストールされる原因となった変更のみをログに記録するにはどうすればよいですか?
• 自己修復の背後にある理由は何ですか?
• Installshield 2008 を使用して MSI の自己修復を無効にするにはどうすればよいですか?

Visual Studio 2008 で MSI インストーラー パッケージを作成しました。問題は、インストール後に、インストールされたファイルのいずれかを削除した場合です。これは、インストーラー パッケージの意図した動作ではありません。マイ ファイルのインストール プロパティは次のとおりです。

PackageAs vsdpaDefault Permanent False ReadOnly False Register vsdrfDoNotRegister System False Transitive False Vital False

これが些細なことである場合は、ご容赦ください。Google に答えをあきらめさせることができなかったなんて信じられません。:)

最近、Entity Framework には、SQL Azure で接続を復元するための非常に簡単な方法があることがわかりました。Dapperで同じことを達成するための推奨される方法はありますか?

Hystrix docs/wikiを読んだだけですが、まだ基本的なレベルで何かが欠けています: implの粒度の意図されたレベルは何ですか?HystrixCommand

たとえば、次のような DB エンティティの CRUD 操作を処理する DAO オブジェクトがあるとしますWidget。

ここで、この DAO が接続するデータベースがダウンすると、すべての DAO メソッドが失敗し始めます。しかし、DB が何らかのトランザクションまたはメンテナンス モードで拘束される可能性もあると思います。たとえば、読み取りは許可されていますが、書き込みは許可されていません。そのエッジ ケースでは、読み取り (getX(...)メソッド) は成​​功しますが、他のすべてのメソッドは s で失敗しSqlExceptionます。

そこで私は尋ねます:ここで使用する必要がある粒度の意図されたレベルは何ですか? また：

1. すべてのDAO メソッドに対して1 つのHystrixCommandimpl を使用すると、コマンドが正常に実行される場合もあれば、失敗する場合もあることがわかります。また
2. HystrixCommand何らかの方法でDAOクラスに焼き付けられ、すべてのDAOメソッドにまたがります(したがって、1つのコマンドが失敗すると、DAO全体が「ダウン」します)?

前者はより柔軟なエンジニアリングを表していると思いますが、ライブラリの消費者である私にはより多くのコードが導入されます。考え？アイデア？

多くのアプリケーションは、回復力のために HTTP 呼び出しと JDBC 呼び出しの両方に接続プールを使用します。ただし、これら 2 種類のプールの使用と構成は大きく異なります。これにより、タイムアウト、再試行、キャッシング/アラート フォールバック、サーキット ブレーカー、監視など、両方に共通する回復力パターンを実装する複雑さが倍増します。

私の考えでは、 Hystrixは、HTTP 呼び出しと JDBC 呼び出しの両方に対して、これらと同じ回復力パターンを構成および実装するための共通のアプローチを提供します。

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

1. Hystrix は、理論的に既存の HTTP および JDBC 接続プールを完全に置き換えることができますか?
2. もしそうなら、そうすることの長所と短所は何ですか？

それらを完全に置き換えると、これらの接続プールを取り巻く複雑さの世界が軽減されます-付随するタイムアウトや検証クエリプロパティなど.これらのタスクに特化した既存のライブラリに委譲します。

コンテキストとして、JDBC 接続プールに Tomcat DBCP を使用し、HTTP 接続プールに Apache HttpClient を使用する DropWizard アプリがあります。

この Hadoopのチュートリアルを読みましたが、Hadoop にはアキレス腱 (単一障害点) があると書かれていますJobTracker。

JobTracker は、Hadoop MapReduce サービスの単一障害点です。つまり、JobTracker がダウンすると、実行中のすべてのジョブが停止します。

また、この記事NameNodeでは SPOFであると述べています。

Hadoop クラスタの単一障害点は NameNode です。

単一障害点は悪いことですよね？どのような戦略/テクニック/ツール/など. これらの SPOF を回避し、Hadoop を冗長性、フォールト トレラント、回復力のあるものにするために実行できることはありますか (バズワード アラート!)?

WCF サービスを Azure に移行するために、Repository クラスに Connection Resiliency を追加してテストしようとしています。Julie Lerman のすばらしい投稿があります。

http://thedatafarm.com/data-access/testing-out-the-connection-resiliency-feature-into-ef6/#comment-61311

通常の Entity Framework クエリを使用するリポジトリ メソッドを呼び出すと、Interceptor ReaderExecuting メソッドがトリガーされ、接続の問題をシミュレートできます。

しかし、何らかの理由で、ストアド プロシージャから返された「複数の結果セット」を使用するリポジトリ メソッドの 1 つが実行されているときに、Interceptor ReaderExecuting メソッドが呼び出されません (以下のコードを参照)。「ObjectContext.Translate」または「ToList」が実行されたときに ReaderExecuting メソッドが呼び出されることを期待していますが、そうではありません。

参考までに、「複数の結果セット」の処理については、この記事に従っています。

https://msdn.microsoft.com/en-us/data/jj691402.aspx

接続の回復力を処理するために、Entity Framework 6+ 実行戦略を中継しようとしています。しかし、複数の結果セットを処理できない場合、私の次のオプションは、一時的な例外処理に Polly ライブラリを使用することです。

このような状況に遭遇したことがありますか?

それに対する解決策はありますか？

私は、呼び出しごとに DB でいくつかの変更を行い、いくつかの応答を返す非常に単純な WCF SOAP サービスを持っています。また、ServiceChannel を使用して、クライアント側のコードから呼び出しています。

サービスが忙しすぎるときにクライアント側のコードが失敗しないようにしたいので、例外がキャッチされた場合にサービス呼び出しを再試行する再試行パターンを実装しました。ただし、WCF サーバー側のコードが原因で例外が発生した場合は再試行したくありません(接続に関連していない場合、またはいずれかの OperationContract コードが実行された場合) (タイムアウトはそうではなかったという意味ではありませんよね? )))。

したがって、次の場合にのみ再試行したい

1. リクエストを送信しました
2. 例外をキャッチしました
3. OperationContract メソッドのサーバー側コードは実行されませんでした

Microsoft の記事 (上記のリンク) には、正確にどの種類の例外が一時的であるかについての情報がほとんどありません。必要なものを正確にキャッチするには、どの例外タイプを使用すればよいですか? または、どのようにフィルタリングする必要がありますか?

Python でカスタム バックアップ スクリプトを作成しています。mkdir 関数や print 関数、その他の関数がさまざまな理由で失敗することがあります。このような例外により、スクリプト全体が停止し、バックアップが途中で停止するため、非常にイライラします。これまでのところ、try: ... except: ... ステートメントを追加し、これらの例外を適切に管理することで、これらの問題に対処してきました。ただし、ある日、まだトリガーされていない他の理由により、他のステートメントまたは関数でも例外が発生する可能性があります。

とにかくスクリプトを続行するように指示する方法はありますか? コードのすべてのステートメントを try: ... except: pass 句でラップするのと同じですか? もちろん、ログの方が良いでしょう。

Tkinter などの GUI ツールキットを使用してプログラミングすると、例外が発生してもアプリケーションが実行され続けることに気付きました。コンソールでこの種のことを達成することは可能ですか?