[Seasar-user:18818] Re: [Teeda] PRG パターンについて

荒浪一城 [E-MAIL ADDRESS DELETED]
2009年 10月 30日 (金) 02:08:11 JST


うちまさんへ

(・∀・)キムティ♪です。


ApacheとJBoss ASを連携する際には、
 ・mod_jk
 ・mod_proxy/mod_proxy_ajp
の組み合わせがあります。


どちらが良いかは一概には言えません。mod_proxy/mod_proxy_ajpは、後発で
扱いが容易です。mod_jkは、細かい設定が可能で、歴史も長く、またJBoss AS
自体がベースがTomcatです。

再現性がない現状では、回避策としてmod_jkを利用することもひとつの解かも。


ちなみに本家FAQでは、以下のように言ってます。

Which connector: mod_jserv, JK, JK2, mod_webapp or mod_proxy?

mod_jk is great and should be used for production. It is still under
active development and also works for the apache 2.X series for cases
where you do not want to use mod_proxy_ajp.

mod_proxy. A cheap way to proxy without the hassles of configuring JK.
This solution lacks sticky session load balancing. If you don't need
some of the features of jk - this is a very simple alternative.

mod_proxy_ajp. With apache 2.2, mod_proxy was rewritten to support
load balancing as well as a new transport called mod_proxy_ajp. This
module is distributed with the Apache http server, not the Tomcat
server.

http://wiki.apache.org/tomcat/FAQ/Connectors#Q2


2009年10月29日12:47  <[E-MAIL ADDRESS DELETED]>:
> うちまです。山本さんレスありがとうございます。
>
> 上司よりインフラ構成の情報をMLで流しても良い許可を貰いましたのでこちらのイン
> フラ構成を記述します。
>
> ・OS: Red Hat Enterprise Linux Server release 5.2 (Tikanga)
> ・HTTP server: Apache/2.2.3 (RHELデフォルト)
> ・Application server: jboss-4.2.2.GA
> ・連携モジュール: mod_proxy_ajp (RHELデフォルト)
>
> バグ情報の提供ありがとうございます。こちらでは把握していない情報でした。おっ
> しゃる通りビンゴの可能性が高いですね。有用な情報ありがとうございました。心か
> ら感謝いたします。
>
> Seasarとは直接関係のない事でメールのやり取りが発生した事お詫び申し上げます。
> また私のメール内容でTeeda、Seasarに関してバグの誤解を招いてしまったなら、心
> より深くお詫び申し上げます。
>
>
>> うちまさん
>>
>> 山本と申します。
>>
>> アプリやインフラの構成が不明ですので、参考になるかわかりませんが、
>>
>>>>> 別セッションに返されるべきレスポンスが帰ってきた可能性がある
>>
>> に遭遇したことがありましたので、投稿させていただきました。
>>
>> 下記のバグレポートはご覧になりましたか?
>> すでに確認済でしたらごめんなさい。
>>
>> [ Apache httpd serves sometimes content from another thread ]
>>   https://issues.apache.org/bugzilla/show_bug.cgi?id=46949
>>
>> Content-Lengthが設定されていて、
>> データ0バイトでPOSTリクエストすると再現するようです。
>>
>> もし、 httpd-2.2.11 で mod_proxy_ajp をご利用であれば、
>> ビンゴの可能性がありますので、ぜひご確認ください。
>>
>> もし該当するようであれば、
>> patch適用かmod_jkへの変更で解決するかと思います。
>>
>>
>> 以上です。
>>
>>
>> 2009/10/29  <[E-MAIL ADDRESS DELETED]>:
>>> (・∀・)キムティ♪さんへ
>>>
>>> うちまです。
>>>
>>>> うちまさんへ
>>>>
>>>> (・∀・)キムティ♪です。
>>>>
>>>>
>>>>> 別セッションに返されるべきレスポンスが帰ってきた可能性がある
>>>>
>>>> これは学生時代(2003年くらい)の経験で、当時大学のに課題提出システムを
>>>> 某企業さんが、JSP/Servletで構築してログインしたところ、問題なく使えました。
>>>> フレームワークは一切使用していない純粋なJSP/Servletです。
>>>>
>>>> ところが、性能実験ということで、学部生数百人で一斉にログインしたところ、
>>>> 自分のログイン情報を入力しながら、他人の別セッションに返されるべき
>>>> レスポンスが帰ってきた経験があります。つまり、本来表示されるべき内容とは
>>>> 全く違う内容が、そのURLで返ってきたと・・・
>>>>
>>>> その時は、「負荷」という再現性がありました。あくまでも「勘」ですが、恐らく
>>>> ロジックのどこかに特定の条件の分岐あたりに謝った処理が混入しているの
>>>> ではないかな?と思った次第です。
>>>
>>> 当方のインフラ環境およびユーザー数では負荷による問題は考えにくいです。負荷テ
>>> ストもテストツールと手動の併用で確認しましたが問題は再現出来ませんでした。
>>>
>>> もしロジックのどこかに特定の条件の分岐あたりに謝った処理が混入している可能性
>>> があるならばTeedaに関わる事も考慮にいれて原因を追究すべきだと思われます。当
>>> 方のアプリケーションはTeedaありきで作成しておりServlet APIを直接操作するよう
>>> な処理は書かれていません。
>>>
>>> またTeedaというフレームワークの性格上、別セッションが返ってくるような書き方
>>> は出来ないはずです。そしてServlet2.3以上のAPIを使用している限りは別セッショ
>>> ンが返される可能性は極めて低いと当方では認識しています。
>>>
>>> でも我々システム開発者は絶対ないとは言い切れないですから、疑えるところは疑う
>>> べきなのでしょうね。
>>>
>>> Servletが別セッションを返す可能性も含めてログを取るなど対策を行ってみます。
>>> また負荷テストも再度方法を変えて行ってみようと思います。
>>>
>>> 貴重な情報ありがとうございました。
>>>
>>>
>>>
>>>> 2009年10月28日22:41  <[E-MAIL ADDRESS DELETED]>:
>>>>> うちまです。キムティ♪さんレスありがとうございます。
>>>>>
>>>>>> うちまさんへ
>>>>>>
>>>>>> (・∀・)キムティ♪です。問題がなければ、どのようなシステム構成で、
>>>>>> ユーザーさんがどのような場面でエラーに遭遇したのかを提示して
>>>>>> いただければトラブルシューティングはうまくいく可能性が高まります。
>>>>>>
>>>>>> この場合、特に障害発生箇所の特定(切り分け)が重要です。
>>>>>>
>>>>>> ・Webサーバーが、アプリケーションサーバー、フレームワーク(Teeda)
>>>>>> のログはどうなっていますでしょうか?もし内容として開示できるよう
>>>>>> でしたら、提示して頂けた方がフォローが増えると思います。
>>>>>
>>>>> 残念ながらログの提示は出来ません。また当方でもマンパワーを投入しインフラ環境
>>>>> も含めてログの確認を行いましたが有用な情報は得られませんでした。正直いってまっ
>>>>> たくの手詰まり状態です。
>>>>>
>>>>> ただ分かっているのはユーザーは特別変わった操作はしていなく(これはログでも確
>>>>> 認が取れました)それにも関わらずURLと画面の内容が違う、画面の内容は恐らくは
>>>>> 別セッションに返されるべきレスポンスが帰ってきた可能性があるという事です。
>>>>> このありえない状況で問題ないであろうと思われるところから箇所を潰していきTeed
>>>>> aが原因の可能性も捨てきれなくなりメールした次第です。
>>>>>
>>>>> 当方のシステムもおよそ一年稼動し動作も安定していると思われた矢先の出来事でし
>>>>> たので本当に参っています。
>>>>>
>>>>> 恐らくは原因不明で再現を待つしか打つ手がなくなってしまそうです・・・。
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Seasar-user mailing list
>>>>> [E-MAIL ADDRESS DELETED]
>>>>> https://ml.seasar.org/mailman/listinfo/seasar-user
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------------
>>>>   荒浪 一城(Kazuki Aranami)
>>>>
>>>>  Email: [E-MAIL ADDRESS DELETED]
>>>>  http://d.hatena.ne.jp/kazuki-aranami/
>>>>  -----------------------------------------------------------
>>>> _______________________________________________
>>>> Seasar-user mailing list
>>>> [E-MAIL ADDRESS DELETED]
>>>> https://ml.seasar.org/mailman/listinfo/seasar-user
>>>> _______________________________________________
>>>> Seasar-user mailing list
>>>> [E-MAIL ADDRESS DELETED]
>>>> https://ml.seasar.org/mailman/listinfo/seasar-user
>>>>
>>>
>>>
>>> _______________________________________________
>>> Seasar-user mailing list
>>> [E-MAIL ADDRESS DELETED]
>>> https://ml.seasar.org/mailman/listinfo/seasar-user
>>>
>>
>>
>>
>> --
>> Ryuzo Yamamoto
>> http://d.hatena.ne.jp/dragon3
>> _______________________________________________
>> Seasar-user mailing list
>> [E-MAIL ADDRESS DELETED]
>> https://ml.seasar.org/mailman/listinfo/seasar-user
>>
>
>
> _______________________________________________
> Seasar-user mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-user
>



-- 
-----------------------------------------------------------
  荒浪 一城(Kazuki Aranami)

 Email: [E-MAIL ADDRESS DELETED]
 http://d.hatena.ne.jp/kazuki-aranami/
 -----------------------------------------------------------


Seasar-user メーリングリストの案内