WebCuratorToolのProfileにて、Writeする際に401レコードを出力しないよう対応することで回避可能
回避例：
WebCuratorTool > Management > profile > Edit > Writers > org.archive.crawler.writer.ARCWriterProcessor > Archiver#decide-rules
に以下を追加
max-retriesのデフォルトが3な為
で終了してしまう。
4にすれば解決。
Thanks for the details – I think the real culprit is this setting, for a non-intuitive reason:[xml]
3 [/xml]
Indeed, if I lower my max-retries to 3 I can reproduce the problem.So a quick workaround: increase your max-retries to 4. You’ll still be running a bit close to the edge – a momentary problem affecting DNS/robots/URI fetching might still push it over the limit – but in a usual situation you’ll succeed.
Another workaround: any other URI against the same site scheduled first would trigger the DNS and robots tries – so when the authentication-needing URI comes up, it would have all its tries left.
FileStore→LocationDB→ResourceIndexと言った具合にマージされる。
Wayback – Resource Store Configuration
デフォルトではResourceIndexにはBarkleyDB Java Edition(BDB)を利用している。
これを編集するのはやや骨が折れる。
WaybackのAPI(libフォルダ内jar)を利用する事で削除可能。
CloseableIterator
UrlCanonicalizer canonicalizer = new AggressiveUrlCanonicalizer();
SearchResultToBDBRecordAdapter adapter = new SearchResultToBDBRecordAdapter(canonicalizer);
while(itr.hasNext()){
CaptureSearchResult result = itr.next();
BDBRecord r = adapter.adapt(result);
System.out.println(BDBRecordSet.bytesToString(r.getKey().getData()));
rs.delete(BDBRecordSet.bytesToString(r.getKey().getData()));
}
}catch(Throwable t){
t.printStackTrace();
}finally{
rs.shutdownDB();
}
[/java]
vps2タグをタグ移動で記録していた場合:
[raw]hg update -r vps2[/raw]
とした場合、上図でのリビジョン20に更新されるわけだが、この時点の.hgtagsにはリビジョン20以前のvps2タグの情報しか記載されていない。
そのため、再度
[raw]hg update -r vps2[/raw]
とすると、古いリビジョンに更新されてしまう。
一旦tipを経由するなどすれば回避可能。
Join Plugin – Jenkins – Jenkins Wiki
Join Pluginで対応可能。
このPluginは上流ジョブで設定を行う。
BuildResultTrigger Plugin – Jenkins – Jenkins Wiki
BuildResultTrigger PluginはコメントによるとどうもOR条件しか設定できない模様？
Jenkins標準と比べると設定するべき場所が下流ジョブだけになるのが利点か。
OSに依存する。
Windowsでは区別されないが、大抵のUnix系OSでは区別される。
MySQL :: MySQL 5.1 リファレンスマニュアル :: 8.2.2 識別子の大文字/小文字区別
MySQL において、データベースはデータディレクトリ内のディレクトリに対応しています。データベース内の各テーブルも、データベースディレクトリ内の少なくとも１つ（記憶エンジンによってはそれ以上）のファイルに対応しています。そのため、ベースとなっているオペレーティングシステムで大文字と小文字が区別される場合、データベース名とテーブル名でも大文字と小文字が区別されます。つまり、Windows ではデータベース名とテーブル名で大文字と小文字は区別されず、ほとんどの種類の Unix では大文字と小文字が区別されることになります。
一般的な慣習とは異なるので分かりにくい。。
PostgreSQLのメジャーバージョンは、例えば8.4のようにバージョン番号の最初の二つの数字の組で表されます。 PostgreSQLのマイナーバージョンは、バージョン番号の3番目の数字の組で表されます。例えば8.4.2は8.4の2番目のマイナーリリースです。 マイナーリリースでは内部データ保存形式は決して変更されず、同じメジャーバージョン番号の以前と以降のマイナーリリースと常に互換性があります。例えば8.4.2は8.4、8.4.1、8.4.6と互換性があります。 互換性のあるバージョン間での更新は、サーバが停止している間に実行ファイルを置き換えサーバを再起動するだけです。 データディレクトリはそのままです。マイナーアップグレードはそのように簡単です。
PostgreSQLのメジャーリリースでは、内部データ保存形式は変更されることがあります。そのため、アップグレードは複雑になります。 新しいメジャーバージョンへデータを移行する伝統的な方法はダンプしてリロードすることです。 他に、以下に記すように、それほどテストされていませんが実行可能な方法があります。
新しいメジャーバージョンは概してユーザから見える非互換性を導入します。そのためアプリケーションプログラムの変更が要求されます。 注意深いユーザは、完全に切り替える前に自分のクライアントアプリケーションを新しいバージョン上でテストしたいでしょう。そのため、旧バージョンと新バージョンのインストールを同時に設定するのは良い考えであることが多いです。 PostgreSQLのメジャーアップグレードをテストするとき、以下に考えられる変更の範疇を検討してください。
らしい。
要するに定数の値を変更しても、それを参照してる側も再コンパイルしないと値が反映されない。
共通ライブラリに定数を定義し、他のプログラムで参照している場合などがヤバイ。
finalなフィールド変数は、値を変更しても、その値を参照している既存バイナリは再コンパイルしない限り新しい値が適用されない。private staticな変数のgetterのみ宣言する方が良い。static finalなフィールドはデフォルト初期値を持つように宣言してはならない。必ず定数式で初期化する。
static final int a;static final int a = 0;ブランクfinalはインライン展開されない模様。
言語仕様では明確な記述は発見できなかった。
static
{
A = “test”;
}
}
class Constant2
{
public static final String A = “test”;
}
public class Main
{
public static void main(String[] args)
{
System.out.println(Constant1.A);
//decompile=>System.out.println(Constant1.A)
System.out.println(Constant2.A);
//decompile=>System.out.println(“test”)
}
}
[/java]
バグ？
Checkstyle4.3.2で確認。
Checkstyle設定画面にてOther＞TreeWalker＞tabWidthを4にする。
SizeViolations＞MaximumLineLength＞tabWidthはバグにより4文字指定不可
設定ファイルをテキストエディタで開き、TreeWalkerモジュールか、LineLengthモジュールに以下のプロパティを設定する。
TreeWalkerモジュールに設定した場合は解決策1と同様の設定になる。