mod_cacheでキャッシュされずに悩んだ話

一部コンテンツがmod_cacheにキャッシュされずに悩んだのが解決したのでメモ。

ググるとだいたいExpiresを設定するように書かれていて大体はこれで解決したけど、さくらのレンタルサーバで動かしているwordpressのfeedがどうしてもキャッシュされない。


まず、mod_cacheの動作状況を調べるため、httpd.conのLogLevelをdebugにしてエラーログを眺めてみる。
すると、以下の様なメッセージが見つかった。

[debug] mod_cache.c(141): not use cache

これで実際にキャッシュが利用されていないことが確認できた。
続いて以下のようなメッセージが見つかった。

[debug] mod_cache.c(583): cache: /blog/feed/ not cached. Reason: Cache-Control: no-store present

これで原因が分かった。
さくらレンタルサーバでお手軽にwordpressをセットアップしたので、ヘッダにno-storeを設定したわけではない。
これを解決するにはphp.iniに以下を追加する。

session.cache_limiter = public

これで解決。

Eclipseのワークスペースがでかくなった時の対処方法

ワークスペースを切り替える。以上

    • -

ワークスペースを切り替えるといろいろと設定が元に戻って困るので、手順をメモ

javadocのフォーマット

exportしておくと吉
Preferences->Java->Code Templates->Comments

tomcat

jspでエラーが出る時の対処

-Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false
-Xmx768M

WordPressでパーマリンクを変更しようとしてハマった話

仕事でWordPressを利用したblogの構築を行った時の話。

サーバはさくらのレンタルサーバを利用することで、WordPressのインストールを省略。
DocumentRoot以下にwpディレクトリが作成され、簡単に利用出来るようになった。

既存サイトへのblogの追加のため、リバースプロキシの設定で「/blog」へのリクエストをさくらレンタルサーバの「/wp」へ飛ばし、WordPressの「サイトアドレス」の設定を「http://xxx/blog」にすることで問題なく準備が整った。

ここまでは良かったが、リリース前にURLの形式が「?p=xxx」だとSEO的にどーなのよということになりパーマリンクの変更を行ったところ、全てのページが「ページが見つかりません」という状態に。
ググると、トップページは見えるけど記事が見えなくなるとかそもそも404になるとか、そんな状況はあるみたいで、その対処を行っても改善されず。

一日悩んで、「WordPressアドレス」と「サイトアドレス」が異なることを思い出し、ドキュメントルートにblogという名前でwpへのシンボリックリンクを作成し「WordPressアドレス」を「http://xxx/blog」へ変更したところ、問題なくページが閲覧できるようになった。

heapに2g以上食わせた場合のjmap

jmapの-Jオプションで-d64を渡さないとダメらしい。

jmap -J-d64 -heap pid

http://www.syboos.jp/opensource/bookmark/detail/20080828165337963.html

これで出力されるファイルのサイズがheapで指定したサイズになった。

PHPでURLエンコードされた文字列をJavaでURLデコード出来なかった話

PHPで実装された外部の決済システムとの連携を行っている。
サイトリニューアルに伴いテンプレートを修正しているのだけど、新たに検索ボックスを追加することになった。

テンプレートはShift_JISと決められているので、Java側ではShift_JISエンコードされた文字が渡されると思い、

String decoded = URLDecoder.decode(keyword, "Shift_JIS");

のようなコードを書いたのだけど、どうもデコード出来ない。
検索ボックスに入力した「フルーツ」という文字が、「%83t%83%8B%81%5B%83c」とエンコードされている。ならJavaならどうエンコードされるのかと思って調べると「%83%74%83%8B%81%5B%83%63」となる。
どうやらphpのencodeurl関数だとこんなエンコードをするらしい。

しょうがないのでcommonのURLCodecのお世話になって解決。

Strutsのセッションが維持できなかった原因

まだまだ元気にStruts1.1で開発してます。

今月からサイトリニューアルを行っていて、ローカルでisTokenValidでコケることが度々あった。
本番だと特に問題ないので気にしていなかったが、ちょっと原因を調べてみた。

ローカルの環境としては、apache<->tomcatで連携している。
tomcatのコンテキストは「/xxx」なのだけど、apacheで「/」->「/xxx」に変換して表からは「/」でも「/xxx」でもアクセス出来るようにしている。

で、セッションが維持出来ないのはこの構成が原因だった。
「/」でアクセスするのは最初だけでlinkタグが出力するのは「/xxx」になるのでセッションが維持できていたのだが、新しく作ったajaxでアクセスする箇所が「/do/yyy」とベタで書いていたため、tomcatがコンテキストが変わったとみなしてセッションを新しくしていたというオチでした。