Curl Global Community

CurlORBでのエラー？？

31 件の投稿

okm質問

こんにちは！

現在、CurlORBを取り入れているのですが、ほぼ毎日1度、以下のようなエラーになり、困っています。
※この状態になったら、画面は反応しなくなり（恐らく処理中）、
　5分ほどして　Curlの予期していないアプレット例外「EndOfStreamException」がポップアップされます。

SocketTimeoutなどから通信が切れたのかと思い、わざと処理途中でネットワークを切断しても、このエラーはでません。
原因がわからないのでいざテストしようとしても再現できないのですが、ほぼ毎日でるようなんです・・。

どなたかご助言願います！

===========================================================
DefaultInstanceManagementFilter - Could not deserialize the object from Curl.
com.curlap.orb.common.InstanceManagementException: Could not deserialize the object from Curl.
at com.curlap.orb.servlet.DefaultInstanceManagementFilter.doFilter(DefaultInstanceManagementFilter.java:97)
========================（省略）===================================
Caused by: com.curlap.orb.io.SerializerException: java.net.SocketTimeoutException: Async operation timed out
at com.curlap.orb.io.CurlSerializableStreamReader.<init>(CurlSerializableStreamReader.java:51)
========================（省略）===================================
Caused by: java.net.SocketTimeoutException: Async operation timed out
at com.ibm.ws.tcp.channel.impl.AioTCPReadRequestContextImpl.processSyncReadRequest(AioTCPReadRequestContextImpl.java:189)
========================（省略）===================================
Caused by: com.ibm.io.async.AsyncTimeoutException(Async operation timed out, [Timeout, rc=0])
at com.ibm.io.async.AsyncException.<init>(AsyncException.java:42)
===========================================================
hokada回答 #1
類似の問題を過去に直したことがありますので、最新で試してもらえないでしょうか？
但し、同一ではないので、申し訳ないですがこれで直るかどうかは分からないです・・。


ちなみに、com.ibm.io.async.AsyncTimeoutExceptionでタイムアウトエラーが起きていますが、こちらは確認されていますでしょうか？
okm回答 #2
hokadaさん

ありがとうございます。
最新に、というのはjarファイルの置き換えとかだけで対応できますでしょうか？
生成からやり直し、でしょうか・・？

>com.ibm.io.async.AsyncTimeoutExceptionでタイムアウトエラー
いえ、なにから手をつければ良いのかもわかっておらず、ただ最初に出ているExceptionがCurlORBのものだったので、
こちらで聞いてみた次第です。

okm回答 #3
hokadaさん

ちなみに、過去にあった類似の問題というのはどのようなものだったのでしょうか？

サーバーサイドにも問題があったのですか？
CurlORBのみの問題だったのでしょうか？

CurlORBを最新にする、というところも至急教えていただければテストしますので、
教えてください。
よろしくお願いいたします。
hokada回答 #4
当問題はサーバサイド側の問題でしたが、ORBを最新版にするには、サーバサイドのみだけでなく、クライアント側のORBパッケージも入れ替える必要があります。

よろしくお願いいたします。
okm回答 #5
hokadaさま

サーバーサイドをORBV0.8に修正し、ジェネレータから生成しようとしているのですが、エラーになってしまいます。
原因分かりますでしょうか？

サーバサイド修正内容
・jarファイル置き換え（lib配下の8つのjar）
・パッケージ変更に伴い、Java修正
・web.xmlの内容置き換え（セキュリティ設定がなくなっていますが問題ないですか？）

V0.8のジェネレータを起動し、デプロイしたサーバをServerURLに入力（URL/コンテキストルート）、
次のclass　nameを空欄のまま、「Browse」しても
Unexpected server exception happened　　というポップアップがでてきてしまいます！

なにか設定が必要でしょうか？
okm回答 #6
上記のエラーは、特になにも設定等変更していないのに、でなくなりました。

それも謎ですが、その後、
class　name　を入力する場面で、クラス名を1文字2文字入力して「Browse」を押しても
「Choose　a class name」には何も入力されておらず、マッチしません。

サーバ側のSystemOutには、以下のように出力されます。


CurlSerializer - The deserialized object is [Header:{} ][Object ID:null ][Class name:com.curl.orb.generator.ClassPropertyLoader ][Method name:getAllClassProperties ][Arguments:null]
DefaultInstanceManagementFilter - Curl ORB Request object [[Header:{} ][Object ID:null ][Class name:com.curl.orb.generator.ClassPropertyLoader ][Method name:getAllClassProperties ][Arguments:null]]
InvokeHttpSessionServlet - Request invoke static method(HttpSession)
DefaultInstanceManagementFilter - Curl ORB Response object: [Lcom.curl.orb.generator.ClassProperty;@1f571f57
CurlSerializer - The serialized object is com.curl.orb.common.InstanceManagementResponse@42314231
DefaultInstanceManagementFilter - Curl ORB has returned serialized object.

V0.7からV0.8にあげることによって、設定等変更すべき箇所があるのでしょうか？
okm回答 #7
すみません

上記2つの質問・エラーについては、こちらの設定ミスでした。
web.xmlにリストアップするような設定が抜けておりました。

申し訳ございません。

今回、修正したのは以下

サーバサイドの修正
・lib直下のjarファイル置き換え（8ファイル）
・パッケージ変更に伴うUI.javaの修正
・パッケージ変更に伴うweb.xmlの修正

Curl側の修正
・COM.CURL.ORBの配置（COM.CURLAP.ORBは不要、あっても影響はなし）
・パッケージ変更に伴うmanifest.mcurlの修正
・ORBSERVER内のscurlを自動生成されたものに置き換え


無事V0.8にバージョンアップできたので、当初のエラーについては今後確認してみます。
okm回答 #8
ORB　V0.8についてもうひとつ質問です！

今回、web.xmlの中に、
session-config　というタグが増えていましたが、
これはどういったものなのでしょうか？

また、クライアントキャッシュ機能が追加されたとのことですが、
その詳細などはどこか記事にありますでしょうか？

よろしくお願いいたします。

okm回答 #9
hokadaさま

今後のために、過去の類似の問題というのはどういったものだったのか詳細に教えていただきたいと思います。

また、web.xml中のsession-configの内容、
クライアントキャッシュ機能の詳細についても教えてください！

お願いします。
okm回答 #10
hokadaさま

CurlORBの最新版（v0.8）でも、当初のエラーが発生してしまいました。
v0.8で修正された類似の問題とは違った現象だったようです・・・。

何の処理をしているときに例外が発生しているのか、どんな原因が考え
られるかなど、ご助言をお願いいたします。

よろしくお願いします。
okm回答 #11
Curl ORB 0.7 は sourceforge にJavaのソースも上がっているのですが、

v0.8 のソースが見つかりません。

curl-orb-server.jar と curl-serializer.jar の各クラスのソースを確認

したいのですが、どちらからダウンロードできますでしょうか？
okm回答 #12
おはようございます！

V0.8のソースはやはり手に入れられないのでしょうか・・。

サーバー側のサポートにも問い合わせしているのですが、以下について聞かれています。


ログのスタックから
---
at
com.ibm.ws.webcontainer.srt.http.HttpInputStream.read(HttpInputStream.ja
va:325)
at java.io.InputStream.read(InputStream.java:97)
at
com.curl.io.serialize.Deserializer.marshal_in_int(Deserializer.java:848)
---
curlアプリケーションが、WASのチャネルを使い、この処理の際に何かしら
の原因で接続先の戻りが遅くタイムアウトになった可能性がございます。
今回いただいたログからは原因を特定することはできませんでした。

■ お客様へお願い
お手数ではございますが、再現時のWASトレースとIPトレースを取得いた
だけますようお願いいたします。
また、上記スタックに関してcurl の
com.curl.io.serialize.Deserializer.marshal_in_int(Deserializer.java:848)
は何かをreadしようとしているようですが、このread先がDataPowerと
いうことでしょうか。
com.curl.io.serialize.Deserializer.marshal_in_int(Deserializer.java:848)
の詳細な動作についてcurl側にご確認いただけないでしょうか。


どうでしょうか。
Deserializer.marshal_in_int　の動作については、何か情報いただけますか？

よろしくお願いいたします。

ashimo回答 #13
sourceforgeの"code"のページにSVNの接続の仕方が書いてありますね。
"code"のメニューから"SVN Browse"を選んで階層をたどっていっても
v8.0のソースが見れます。

curl-serializer.jarのソースはないようですが。
okm回答 #14
ashimoさん

ありがとうございます。
そんな機能があるんですね！

ただ、やはり curl-serializer.jar はソースみれないのですね・・。
okm回答 #15

CurlORBでエラーが発生している件ですが、
サーバ側やCurlORB内でExceptionで落ちてしまっているのを、
画面側までエラーを通知するような仕組みにはできないでしょうか？

現在、5分程度画面が戻ってこず、5分待たないとアプレット例外もでない状況です。
これを、サーバからExceptionが発生したときにCurlの画面側でキャッチできるようにできないでしょうか？

ashimo回答 #16
ORBServerExceptionが返ってくるはずですから、それをcatchするとよいのでは。

以下に記載されています。
http://developers.curlap.com/re-referenc...ption.html
okm回答 #17
ashimoさん

ありがとうございます。

詳細が分かってきました。

クライアントが○○byteのデータを送ります、と宣言するものの、
何らかの影響で実際にはデータが送れなかった場合に発生するようです。

その場合、サーバー側は5分間なにも戻していないようです。

なぜデータが送れなかったかはこれから調査が必要ですが、
Curl側できちんとデータが送信できたかどうかのチェックができれば、解決できそうです。

Curlではそういったチェックはしていないということになるのでしょうか？

ashimo回答 #18
(10-18-2012, 11:37 AM)okm Wrote: クライアントが○○byteのデータを送ります、と宣言するものの、
何らかの影響で実際にはデータが送れなかった場合に発生するようです。

これは、contentのないPOSTリクエストが発行されているということでしょうか。
確認はどのようにされました？


okm回答 #19
ashimoさま

ご返信ありがとうございます。
返信遅れてすみません。

確認は、以下のトレースを取得して行いました。
・クライアントのIPトレース
・HTTPサーバ側のプラグインのトレース
・HTTPサーバのアクセスログ

まずクライアントのIPトレースは、一度POSTし、その後に続くPOSTがないままHTTPのリクエストが戻ってくるまでまっている。
※正常時は、Curlは/new-instance /invoke-http-session /destroy-instance と3度POSTするようです。
　NG時はパターンありまして、/new-instanceのあとにHTTPからのResponseがcontentLength:0　で戻ってくるか/invoke-htt-sessionのあとかの違いがありました。

プラグインのトレースは、
lib_htrequest:htrequestWrite: content length is 138　
とでるのですが、以下のWARNINGがでてBodyが取得できなかったようです。
TRACE:mod_was_ap22_http:cb_read_body: Failed to read the full body from the browser. just_read = -1 of the expected 138
TRACE:lib_htrequest:htrequestSetError: Setting the error to: |READ_FAILED|(1,Line: 1620)
WARNING:ws_common:websphereExecute: Error reading post data from client
DEBUG:lib_stream:destroyStream: Destroying the stream
TRACE: lib_rio:rcloseConfusedocket 15 closed

HTTPサーバのアクセスログは、バイト数も出力するよう設定してあるのですが、「-」になっており、

以上からクライアントからデータが送られてないと判断しました。

解決できず困っています・・。
kim回答 #20
とても興味深く拝見しました。

「Curlからのデータがサーバに到達していない。」
ということですので、問題は
　クライアント（Curl）、ネットワーク、サーバ
の何れかにありますね。

３つのどこに問題がありそうか アタリ をつけるために、
クライアントとサーバ側にパケットキャプチャをしこんで確認するのがよいと思います。


●クライアント側にパケットキャプチャをインストールして
　　・Curlのコードで書かれたデータがパケットキャプチャにて
　　　HTTPリクエストとして 正しく出力されているか
　を確認する。

●サーバ側にパケットキャプチャをインストールして
　　・Curlのコードで書かれたデータがサーバ側に到達しているか
　　　パケットキャプチャにて確認する


「クライアントからのHTTPリクエストが正しく、サーバ側でデータが到達していない。」
というのであれば、ネットワークかサーバ側に問題があると思いますので、
サーバ側のAPサーバをtomcatなどに変更してエラーが出るか確認するのも有効かと思います。



okm回答 #21
kimさま

ありがとうございます。

クライアント側のキャプチャですが、HTTPで送信できていないような気がします・・。
※キャプチャソフトの見方を理解し切れておらず、はっきり言えずすみません。

Frame# Time Tongueort Tongueort Info
33339 11:27:30.216 :1811 -> :80 SYN
:
33347 11:27:30.222 :1811 -> :80 POST /SMAP_UI/new-instance HTTP/1.1
33348 11:27:30.228 :1811 <- :80 ACK for #33347

(300秒) POST dataは送っていません

150545 11:32:30.464 :1811 <- :80 HTTP/1.1 200 OK
:


サーバー側にキャプチャは仕込んでないのですが、HTTPサーバのアクセスログはバイト数なしでした。

access.logにも受け取ったbyte数が表示されていません。※下記赤字部分
-----
128.1.1.XXX - - [17/Oct/2012:11:25:23 +0900]
"POST /SMAP_UI/destroy-instance HTTP/1.1" 200 64
128.1.1.48 - - [17/Oct/2012:11:24:56 +0900] "POST /SMAP_UI/new-instance
HTTP/1.1" 200 -
128.1.1.XXX - - [17/Oct/2012:11:30:40 +0900]
"POST /SMAP_UI/acKeepSession.do HTTP/1.1" 200 74
-----


CurlからHTTPで送られていない、なんてことも考えられるのでしょうか？
kim回答 #22
33347 11:27:30.222 :1811 -> :80 POST /SMAP_UI/new-instance HTTP/1.1
の行にてクライアントからサーバにリクエストを出していて その結果として、サーバより
　150545 11:32:30.464 :1811 <- :80 HTTP/1.1 200 OK
が返却されているのでクライアントのログからはサーバも「正常」と処理しているように見えますね。

クライアントからの送信は正しいように見えますので、ネットワークかサーバを調べてみたほうがよさそうですね。
okm回答 #23
kimさま

ありがとうございます。

すみません、
　150545 11:32:30.464 :1811 <- :80 HTTP/1.1 200 OK

この200 OK は、HTTPサーバのバグでして、本来は400を返さなければならないものなんです。

うちがFixPackをあててないんです・・。

200が返ってきてるんですが、中身は400でして、
Curlは正常データが戻ってきたと思って普通に読み込もうとして、 EndOfStreamException が発生してしまいます。
kim回答 #24
(10-31-2012, 04:46 PM)okm Wrote: うちがFixPackをあててないんです・・。

200が返ってきてるんですが、中身は400でして、
Curlは正常データが戻ってきたと思って普通に読み込もうとして、 EndOfStreamException が発生してしまいます。



サーバのバグとのことなんですね。　Curl側では　200のつもりで処理しているわけですからサーバを正しく直せば解決できそうですね。

サーバのアクセスログでサイズが-となっているのもバグが影響してそうですね。
okm回答 #25
kimさま

うーん、アクセスログのサイズ-までがバグという認識はありませんでした。
サーバー側のサポートもサイズは信用しているようでした・・。

このFixPackをあてて、200を400にしたところで、結局Curlのエラーになると思います。
問題は、Curlがデータをきちんと送れていないのではないか、と疑問があがっていることです。
データをきちんと送れていれば、サーバが200を返しても問題はないはずですからね・・。

Curlがデータを送れているのか疑問にあがっているのは、サーバのサポートセンターから以下のように言われたからです。

「クライアントのIPトレースを確認したところ、クライアント側からデータを送付していないことが確認できました。」
2つ前の投稿のクライアントのIPトレースがそれなんですが、こうはっきり言われましたら疑ってしまいますよね。

クライアントの問題なのか、ネットワークの問題なのか、いまいちハッキリできておりません！
はやくスッキリしたいです！
nasuB回答 #26
久しぶりに来てみたら、めっちゃ長いコメント・・・。
この「本当は400で返す」とか「FixPack」って何のこっちゃわからないが、最初にIBMのエラーが発生していたということから、WebSphereを使っているっぽいけど、そもそも、このエラーが発生しているということはサーバに何らかは到達してるのでは？このエラーの原因はよく分からないけど、例えばサーバが問題か否かは、Tomcatなどにスイッチして同様の問題が発生するか調べてみたらどうだろう。（もしくはパッチはあててみて試したのかな。）
クライアントからACKを返しているところからコネクションは張れているようで、CurlではHTTP通信でWinInetを使っているようで（以下参照）、WinInetをデバッグしてみたらどうだろう。
http://developers.curlap.com/faq/49-faq-...llapi.html
http://d.hatena.ne.jp/pekeq/20050325/p2

また、ネットワーク的にもVPN、プロキシー、バランサー、スイッチなどなど含めクライアントーサーバ間のどこまで到達してるかどうかを総合的に確認することで、問題は発見できる可能性があると思う。
この手の問題は、手当たり次第メーカに聞いても、どうせ自分たちの環境／構成をわかっている訳ではないので、それぞれの範囲でしか回答してくれず、たらい回しにされるだろうから、アプリ、インフラ、ネットワークを現在総合的に見ている保守担当者によって手順を踏んで問題切り分けしないとなかなか解決に至らないと思いナス。
-B


okm回答 #27
nasuBさん

アドバイスありがとうございます。そうですよね、すごい量・・。また大量に書くけど･･。

流れを整理すると・・
ユーザーから以下のような報告があり「仕事にならない！」と怒られAngryました。
検索ボタン押下
　↓↓
300秒待機
　↓↓
Curlアプレット例外発生！（EndOfStreamException）

そこでまず最初のSyslogを発生時間から突き止め、Curl、IBMに問い合わせました。
Curl→CurlORBはオープンソースなのでSNSできいてくれ　→今に至る
IBM→再現時のログを取得してくれ

IBMの報告
・HTTPのプラグインのデフォルトTimeOutが300秒
・WASのチャネルのTimeOutが60秒
・クライアントから○○bytes送りますよ！という情報は受け取った。
　しかしその後データが送られてこず、WASのTimeOut（60秒）が発生
　　→Syslogの最初にWASが吐いているExceptionはこれ。
　クライアントのキャプチャをみても、POSTは一度きりでその後送られてきていない（CurlORBは一度のサーバーアクセスで3度POSTする）
　※ここの根拠は今まで出したとおり、クライアントのキャプチャやHTTPサーバ、プラグインのログなどから判断
・そもそもHTTPサーバにバグがあり、300秒経過してTimeOutになった際に400を返すべきだが、200OKを返してしまっている

IBMの報告を受けて、Curlの動きを推測
・データを全て送りきれていないのを感知できていないのでは？　→Curlのバグ？
・HTTPサーバが200OKを返しているのでCurl的にはOKと思っていてResponseを読み込もうとしたけど
　実際は400の内容が返ってきているので辻褄が合わずEndOfStreamExceptionが発生している　→Curlの動き的には正しい。

こちらで試したこと
・CurlORBのsend.scurlにtry～catchを仕込んで、catchされたらsend処理をもう一回
　→2度目のループで問題なく検索処理が完了した。（※画面からsend処理の間にデータがなくなったわけではない）
・プラグインTimeOutを短縮
　→検索ボタン押下から300秒待たなくなったが根本解決ではない。全然ない。

Wininetのデバッグなんぞは知りませんでした。
リンク先よくよく読んでみます。
(11-01-2012, 01:25 PM)nasuB Wrote: この手の問題は、手当たり次第メーカに聞いても、どうせ自分たちの環境／構成をわかっている訳ではないので、それぞれの範囲でしか回答してくれず、たらい回しにされるだろうから、アプリ、インフラ、ネットワークを現在総合的に見ている保守担当者によって手順を踏んで問題切り分けしないとなかなか解決に至らないと思いナス。
仰るとおり！
必ず発生する事象だと総合的に確認が取れるのですが、毎回じゃないんです・・。
いつ発生するかわからないので一日中バグを仕込んでおく･･なんてことは到底出来ず。。
仕事ができないと言われていたので超急ぎ案件だったこともあり（もう1ヶ月ですが・・）、まずそれぞれのメーカーにきいて問題の切り分けないし解決したかったのです。
nasuB回答 #28
文章長すぎてちゃんと読んでいナスですが、
問題切り分けは保守・運用者の腕の見せ所だと思います。

がんばってください。

-B
okm回答 #29
熱意あふれすぎですみません（笑）

まとめると、
クライアントのキャプチャをみるとデータを完全にPOSTできていないので、
①Curlでsend処理時に欠損（？）しているか
②CurlからクライアントのTCPIPにのる間に欠損（？）しているか
のどちらかだと思っています！

4行になりましたｗ

①ならCurlのバグじゃないの？
②かどうかは、教えてもらったデバッグがどう試せるか・・ってとこですかね・・。
herring回答 #30
okmさん

はじめまして。

ORB0.8にて同様のエラー、状況（日に1度出るかどうか、再現性乏しい）にあったのですが、
本件その後はどうなったのでしょうか？
なにか解決策・回避策などがあればご教示いただけないでしょうか。

↓以下エラーログ（一部抜粋）
[com.curl.orb.servlet.DefaultInstanceManagementFilter] [http-8080-1] - Could not
deserialize the object from
Curl.
com.curl.orb.common.InstanceManagementException: Could not deserialize
the object from Curl.
at
com.curl.orb.servlet.DefaultInstanceManagementFilter.doFilter(DefaultInstanceManagementFilter.java:97)