警告: Error sending end packet
Webブラウザでレスポンスが帰ってくる前に何度もクライアントから複数のボタンをクリックすると、
2008/08/07 11:41:46 org.apache.jk.core.MsgContext action
警告: Error sending end packet
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:537)
at org.apache.jk.common.JkInputStream.endMessage(JkInputStream.java:127)
at org.apache.jk.core.MsgContext.action(MsgContext.java:305)
at org.apache.coyote.Response.action(Response.java:183)
at org.apache.coyote.Response.finish(Response.java:305)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:205)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)
2008/08/07 11:41:46 org.apache.jk.common.ChannelSocket processConnection
警告: processCallbacks status 2
という例外が発生する。
想定を超えたリクエストをサーバ側に送信した事によって、コンテナのアプリケーションが処理できず、リクエストの処理中にサーブレット・ゲートウェイのタイムアウト時間に達し、接続が切断された為。
Tomcatの8009ポートのタイムアウト時間を延ばしてみることにより、回避できるか確認してみる。
ログのローテート
Windows 2003 Server にある Apache 2.2 のアクセスログとエラーログが大きくなったので、1週間単位でローテートすることにした。
apachedir/conf/httpd.conf のアクセスログ（CustomLog）とエラーログ（ErrorLog）の内容を変更する。
アクセスログは以下のようになっている。
#
# The location and format of the access logfile (Common Logfile Format).
# If you do not define any access logfiles within a <VirtualHost>
# container, they will be logged here. Contrariwise, if you *do*
# define per-<VirtualHost> access logfiles, transactions will be
# logged therein and *not* in this file.
#
CustomLog "logs/access.log" common
#
# If you prefer a logfile with access, agent, and referer information
# (Combined Logfile Format) you can use the following directive.
#
#CustomLog "logs/access.log" combined
この
CustomLog "logs/access.log" common
をコメントアウトして
CustomLog "| bin/rotatelogs.exe logs/access_%Y%m%d.log 604800" combined env=!nolog
を追加した。
apachedir/logs フォルダに access_20080717.log のようなアクセスログファイルができる。1週間単位でローテートさせるため、60秒×60分×24時間×7日＝604800 を設定した。
エラーログは以下の通りになっている。
# # ErrorLog: The location of the error log file. # If you do not specify an ErrorLog directive within a <VirtualHost> # container, error messages relating to that virtual host will be # logged here. If you *do* define an error logfile for a <VirtualHost> # container, that host's errors will be logged there and not here. # ErrorLog "logs/error.log"
この
ErrorLog "logs/error.log"
をコメントアウトして、
ErrorLog "| bin/rotatelogs.exe logs/error_%Y%m%d.log 604800"
を追加した。こちらも1週間単位でローテートするようにした。これで運用をしてみてログの大きさがどの程度になるかを確認し、大きいようであれば毎日ローテートするように変更する。
http://www.nori12.com/lofviewer.htmlを参考にした。
XHTMLのXML宣言をするとNiceformのテキストイメージがずれる
僕みたいな天才的なデザインセンスのなさを持っている人間にとって見栄えの良いフォームを作るのは大変である。HTML でフォームを作成するとひとりでにすばらしいフォームになってしまうという夢のような CSS & Javascript がある。Niceformというサイトにそれはある。
このサイトで提供してくれている CSS & JS & イメージでフォームを作成したのだが、IE6 でテキストボックスを表示すると、コーナーと上下線の位置がずれて表示される。Firefox3では、正常に表示される。わかりづらい文より実際のイメージを見てもらうとわかると思うので、イメージをアップする。
Niceform のサンプルサイトを IE6 で見ると正常に表示される。ほとんど一日悩んでしまい、最後の手段で、正常に表示されている Niceform のサンプルサイトの HTML をダウンロードして、テキストボックス以外の余分なタグを削除した。もちろん正常に表示されている。ここから少しずつタグを追加していったところ、イメージが崩れることはなかった。
それで両者（正常に表示されている HTML とイメージが崩れている HTML）の違いを見てみると、イメージが崩れている HTML には、というXML 宣言があった。これを外してみると正常に表示された。
もちろん XHTML では XML 宣言文を記述することは強く推奨されていることだが、IE6 ではレンダリングが互換モードになってしまい、表示がおかしくなるという既知の問題があるようだ。
衆知の問題ではあるが、xml宣言をすることでWinIE6.0以下のバージョンのブラウザにてレンダリングが互換モードになり、表示がおかしくなると言う事がまず上げられる。また、古いブラウザ（MacIE4）などで、xml宣言がそのままブラウザ上に表示されるという問題もある。
http://hato-style.chu.jp/note/note_20070314.html
フレームワークの構想 5日目
アクティビティをサービスレベルの粒度とするほうが管理がしやすいかもしれない。それともユースケースレベルの粒度がいいかもしれない。ユースケースを実行できるアクターはシステムユースケースを作成した時点で決まるので、その定義に基づいて設定していけばよいので、設計から実装に落としやすいというメリットがあると思う。1ユースケース＝1サービスで設計していることを思うと、ここでなんだかんだ言っていたサービスレベルの粒度やユースケースレベルの粒度というのは、つまり同じことを言っていたのかもしれない。ということで、サービスレベルの粒度でアクティビティを設定することにする。
たとえば、グループカンパニーがあり、全社に同じアプリケーションを導入する。アプリケーションの運用管理者は、各会社の運用管理者を任命しその会社内のすべてのアクセス権を与える。各会社の運用管理者は自分の会社のアクセス権はあるが、ほかの会社のアクセス権はなくほかの会社の情報を見ることはできないようにする。経費精算はその会社の全社員が行うことができ、経理処理は経理部の社員のみ行うことができるようにしたいという要件が当然ながらあると思う。それをこのフレームワークでどのように解決していくかを考えてみよう。
まず、アクティビティを定義することから始めてみよう。アクティビティは「勘定区分を保守する」、「経理精算申請をする」、「経理処理をする」という3つが導出された。
また、ロールとしては、「管理者」、「経理担当者」、「社員」が導出される。
グループとしては組織グループである「会社A」、「経理部（会社A）」、「その他の部署（会社A）」、「会社B」、「経理部（会社B）」、「その他部署（会社B）」が導出された。その他の部署というのは、とても大雑把だが、もっと組織に即したグループが導出されるかもしれいない。
あと、役割グループである「管理グループ」、「経理グループ」、「社員グループ」が導出される。
役割グループの「管理グループ」は「管理者」ロールに、「経理グループ」は「経理担当者」ロールに、「社員グループ」は「社員」ロールに割り当てられる。
組織は再帰的に割り当てることができ、「経理グループ」には、「経理部（会社A）」と「経理部（会社B）」が、「社員グループ」には、すべての組織グループが割り当てられる。
ユーザーとしては、会社Aの経理部にはA,B,Cさん、その他の部署にはD,E,Fさん、会社Bの経理部にはG,H,Iさん、その他の部署にはJ,K,Lさんが所属している。
Javascript で躓いた class 属性編
prototype.js を利用した Javascript を IE6 で実行したときに、Companion.JS が Syntax error (line 1) とエラーを表示した。1行目でエラーが出てしまい、作成したクラスすべてが動作しなくなったため、ボタンを押しても何をしても Companion.JS が追加のエラーを吐きまくっていた。Teeda で動的に span 要素に class 属性を追加するコードを書いたのだが、Javascript でその属性を削除するコードを書いた（つもり）のが、原因だった。
... function ajax_foo_indexPage_ajaxGetProp(res) { $('bar').innerHTML = res; $('bar').class = ""; //class 属性を破棄するコードと考えていた。 }
$('bar').class = ""; というコードは、実際には100行目なのだが、1行目でエラーを検知したため、何が何だか分からなくなってしまい、1時間ほど悩んだ。正しくは $('bar').className のようだ。
ちなみに Firefox 3 だと、エラーは発生しなかった。
