セッションID用クッキーの上書きを避ける
基本的には、「Weblogicに複数アプリケーションをデプロイ - きょうのできごころ@はてな」に書かれている通りで、複数のJ2EEアプリケーションに、同一FQDN*1でアクセスする場合は、セッションID用のクッキーが上書きされてしまうのを避ける必要があります。
そのためには、weblogic.xmlでcookie-nameかcookie-pathを変更することになりますが、ここではその際の注意点を補足しておきます。
<追記>
上書きが問題になるのは、同一FQDNで異なるWebLogicインスタンス/クラスタにデプロイされているアプリケーションにアクセスする場合です。
同一のWebLogicインスタンスで複数のアプリケーションが存在する(=コンテキストルートが異なる)ケースは普通にあります。デフォルトのセッション管理設定*2を用いる場合、異なるコンテキストルートに対し同一のJSESSIONIDでアクセスすることになりますが、この場合は内部で適切にセッションを分けて管理してくれるため問題になりません。
cookie-name
前段にApacheなどWebサーバがいて、WebLogicクラスタに負荷分散を行うような構成は、割とポピュラーだと思います。デフォルトのJSESSIONIDからクッキーの名前を変更する場合、Webサーバのプラグイン設定でCookieNameも合わせておきましょう。そうしないと、リクエストごとに(デフォルトでは)ラウンドロビンでの振り分けとなり、セッションが正しく継続されなくなってしまいます。
また、負荷分散装置などでも、クッキーを参照する場合があるので、アプリケーション開発者の都合で勝手にクッキー名を変えるのではなく、インフラ担当者と相談したほうがよいでしょう。
第4回 WebLogic Server勉強会@東京 に行ってきた
http://www.oracle.com/goto/jpm091029_5/
いつも申し込もうと思ったら、満席御礼で締め切りの勉強会。今回は制限を緩めてくれたのか、申し込みに余裕があったので間に合いました。
といっても、100人以上は参加者がいたので、かなりの盛況ぶりでした。
内容は以下の通り。
- JRockit JVMのGCアルゴリズム概要とチューニングポイント
- Oracle WebLogic Serverのチューニングのキホン
- 経験者が語る、Spring Frameworkを使ったリファクタリングの実践
今までの経験と、現在の仕事の性質上、ほとんど知っていることばかりでしたが、あらためて頭を整理できたのは有意義でした。
主宰者の皆様、スピーカーの皆様ありがとうございました。
懇親会にも参加し、楽しんできました。勉強会というオープンな場より、懇親会などのクローズな場の方が、コアな部分で盛り上がれるのかもしれませんね。
# 後でまた、追記するかもしれません。
パイプを使いつつ、簡単に終了コードを取得したかったが・・
command 2>&1 | tee command.log
とかやって、command の標準出力を画面上でも確認しながら、ログにも出力したい、というケースは割とあると思います。
ただ、command の実行が成功したかどうかも知りたい。単純にパイプでつなげてしまうと、一番最後のコマンド(この場合は tee)の終了コードしか取れないんだよね。
まあ、でも簡単に取得できるよね、と思ったら、意外と試行錯誤してしまったという話。
前提知識
コマンドをグルーピングするためには、丸括弧「()」と中括弧「{}」が利用できます。
- 丸括弧でグルーピングしたものは、サブシェル(子プロセス)で実行される
- 中括弧でグルーピングしたものは、カレントシェル(自プロセス)で実行される
という違いがあります。例えば、
hoge=0 (hoge=1) echo $hoge # ->「0」が出力される。(子プロセスで変更しても自プロセスには影響を与えない)
hoge=0 { hoge=1; } echo $hoge # ->「1」が出力される。(同一プロセスで実行しているので変更される)
ということになります。
試した方法
カレントシェルで実行して、終了コードを変数に保存すればいいだけじゃん、と思って対話シェルで軽く試してみる。
{ command; status=$?; }; echo $status
動作確認OKだったので、スクリプトファイルに以下を記述。
{ command; status=$?; } 2>&1 | tee command.log if [ $status -eq 0 ]; then # 何かコマンド fi
実行すると、testコマンド([ $status -eq 0 ]の部分)の引数が足りてないよ、ってエラーが。
「sh -x <スクリプトファイル>」で実行すると、確かにstatus変数が空になっているみたい。*1
再度、対話シェルでリダイレクトやパイプも追加し、試してみる。
{ command; status=$?; } 2>&1 | tee command.log echo $status
あれ?ちゃんと取れるじゃん!Windowsのコマンドプロンプトみたいに、対話シェルと実行時で動きが違うんだっけ??
ちょっと混乱。・・・気づきました。対話シェルはbashで実行してて、スクリプトファイルの実行は古きよき /bin/sh(Bourne Shell)です。そういえば、Bourne Shellでは中括弧「{}」で実行しても、リダイレクトを利用するとサブシェルで実行されてしまうんだっけ。*2
bash(など最近のシェル)では、この動きが改善されており、リダイレクトを使ってもカレントシェルで動作するようになっているようです。bashが利用できればよかったんだけど、今回は色んな環境で動作させたかったのでBourne Shellの利用が前提です。無念。
念のため
{ command 2>&1; status=$?; } | tee command.log echo $status
と標準エラー出力のリダイレクトを中に入れてみたが、パイプはリダイレクションと同様に扱われるので、やはりstatusは取得できず。そんな甘くはなかったようです。
パイプを使いつつ、(多少手間をかけて)終了コードを取得する方法
- ファイルディスクリプタを活用する (適当に書いたので間違っている可能性高し)
status=`exec 3>&1; { command 2>&1 3>&-; echo $? 1>&3; } | tee command.log 1>&2 3>&-` echo $status
知っている人が見れば分かるのでしょうが、トリッキーでメンテナンス性はお世辞にもよいとは言えない。
- ファイルに終了コードを書きこんでしまう*3
status_file=/tmp/status.$$ # 中括弧じゃなくて丸括弧でサブプロセスで動作させても全然OK。 (command; echo $? >$status_file) | tee command.log status=`cat $status_file` rm -f $status_file
そんな複雑でもない(むしろ簡単と言える)が、わざわざファイルを介すのが多少冗長かなと。ただ、汎用性が高く、リモートシェルを使っている場合にも応用できるテクニックです。
やはり、これを使うのが現実解かもしれませんが、なんか、他に(Bourne Shellでもっと簡単にできる)いい方法はないもんですかねぇ。
Oracle WebLogic Server 10g 管理者試験
Oracle WebLogic Server 10g 管理者試験を受けてきました。結果、合格。
今の仕事上、落ちるわけにはいかないので、とりあえず受かってほっと一息。
連休中で時間も最後の枠(16:00〜)だったにも関わらず、受験者が(みんな基本的に別の試験だけど)15人くらいとかなり多かった。
別に資格があるから仕事が来るってわけでもないと思うが、なんでだろう?ま、自分もその一人なわけですが。
場所は新宿エルタワー6FのISAキャリアカレッジ。プロメトリックの試験はいつも大抵、高田馬場で受けてきたんだけど、今日は空いておらず。
でも、Oracle認定資格試験の「プロメトリックでの受験は2009年9月25日(金)で終了します」
ってことなんで、今後はどこで受けようかね。
IDG Direct閉鎖
IT情報誌を刊行しているIDGジャパンのオンラインショップであるIDG Directが閉鎖されてしまうらしい。
定期購読している雑誌:ITアーキテクトも休刊になってしまうみたい。といってもほとんど読めてなかったですが。
IDGジャパン自体も含め、雑誌業界全体が厳しい状況なのでしょうね。
以前、「cbook24 リニューアルって - yamadamnのはてな日記」で、cbook24の閉鎖をPASSJからのメールで知ったと書きましたが、そのPASSJ自体も6月末で閉会。
様々な理由があるにせよ、自分が利用していたものがなくなっていくのは少々寂しいものです。
WebLogic用にApacheを構成しようとして少々はまる
Solaris10上で、WebLogic9.2用にApache2.2を構成させようとしたときの話。
$ PATH=/usr/local/bin:/usr/bin:/usr/ccs/bin; export PATH $ LD_LIBRARY_PATH=/usr/local/lib:/usr/lib; export LD_LIBRARY_PATH $ $ cd /usr/local/src $ gzip -dc httpd-2.2.11.tar.gz |tar xvf - $ cd httpd-2.2.11 $ $ ./configure --prefix=/usr/local/apache2 $ make $ make install
で、バージョンの確認。
$ cd /usr/local/apache2 $ ./apachectl -V
ld.so.1: httpd: 重大なエラー: /usr/local/lib/libgcc_s.so.1: ELF クラスが正しくありません: ELFCLASS32 強制終了
ということで、libgccの64bit対応版を指すよう設定。
$ LD_LIBRARY_PATH=/usr/sfw/lib/sparcv9:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH $ ./apachectl -V
Server version: Apache/2.2.11 (Unix) Server built: Jul 30 2009 09:44:58 Server's Module Magic Number: 20051115:21 Server loaded: APR 1.3.3, APR-Util 1.3.4 Compiled using: APR 1.3.3, APR-Util 1.3.4 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with.... (以下略)
これで、Apacheが64bitになっている。
httpd.confのServerNameを書き換えてから設定を確認。
$ ./apachectl -t
Syntax OK
次にhttpd.confに以下を追記。
LoadModule weblogic_module modules/mod_wl_22.so
WebLogicのプラグインをモジュールディレクトリにコピーしてから、設定を再確認。
$ cp -p /opt/bea/weblogic92/server/plugin/solaris/sparc/mod_wl_22.so /usr/local/apache2/modules/ $ ./apachectl -t
httpd: Syntax error on line 411 of /usr/local/apache2/conf/httpd.conf: Cannot load /usr/local/apache2/modules/mod_wl_22.so into server: ld.so.1: httpd: fatal: /usr/local/apache2/modules/mod_wl_22.so: wrong ELF class: ELFCLASS32
プラグインモジュールを確認してみる。
$ file modules/mod_wl_22.so
modules/mod_wl_22.so: ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped
32bit版じゃ動くはずないよね。ということで64bit版のプラグインを探してみるも見つからず。
Solaris用のプラグインは32bit版しか(今のところ)ないことに、この時点で気づく。(泣)
というわけで、結局Apacheを32bitで再コンパイルことに。
$ gcc -v
(省略) gcc version 3.4.4
このバージョンはデフォルト64bitでコンパイルするみたいなので、明示的に32bitを指定。
$ rm -fr /usr/local/apache2 /usr/local/src/httpd-2.2.11 $ cd /usr/local/src $ gzip -dc httpd-2.2.11.tar.gz |tar xvf - $ cd httpd-2.2.11 $ $ CC="gcc -m32" ./configure --prefix=/usr/local/apache2 $ make $ make install
Gmail Labsの「全員に返信」をデフォルトにする機能がなくなってしまった
Gmail Labsで結構重宝していた「常に全員に返信」が無効にされてしまったようです。
「ロケーション付き署名」に続き申し訳ございませんが、Labs の「常に全員に返信」を一時的に無効にさせていただきました。
http://www.google.com/support/forum/p/gmail/thread?tid=20b169c4debd8373&hl=ja
ご利用の皆様にはご迷惑をおかけしますが、ご理解のほどよろしくお願いいたします。
"一時的に"とあるから何か問題があって、解決すれば復活するのだろうか?
ちなみに機能の詳細はこちらから確認できます。
細かい使い勝手を改善するものだけど、Labsでなくても標準の機能として組み込まれて、設定で変更できてもよいと思う。まあ、Gmailはあまり設定項目を増やそうとは考えてないみたいなので、それはないのでしょうね。
右上の[返信]を押してしまうと、毎回リッチテキスト形式をデフォルトにされてしまうのも如何なものかと。本文下側の[返信]ではテキスト形式になるし、[全員に返信]も直接選べるので、こちら側に慣れるしかないのかな。。