From nakano.hiroaki @ nttcom.co.jp Wed Nov 5 15:14:48 2014 From: nakano.hiroaki @ nttcom.co.jp (Hiroaki Nakano) Date: Wed, 5 Nov 2014 15:14:48 +0900 Subject: [Ultramonkey-l7-develop 1077] Re: tmp_v3.1.2-1 upload In-Reply-To: <5434DF5C.9000003@nttcom.co.jp> References: <54110A0F.2050109@nttcom.co.jp> <5412ABDA.2070909@lab.ntt.co.jp> <541A68D6.8010904@nttcom.co.jp> <542BA4B0.8010802@nttcom.co.jp> <542BAA09.5090803@nttcom.co.jp> <542D25BC.9040201@lab.ntt.co.jp> <5433A024.2010300@nttcom.co.jp> <5434DF5C.9000003@nttcom.co.jp> Message-ID: <5459C058.4070108@nttcom.co.jp> 中野@幕張です。 これって結局発生条件わかったんですかね。 自分の検証環境では再現しないんですが、色々調べたところ try againしちゃいけない通信パターンでerror codeにtry_againが 発生してませんか? boost/asioのSSLのshutdownハンドラとboost/system/error.hppや boost/asio/error.hpp を見ていると、SSL shutdownでのリターン値や SSL_get_error(3)をまともに拾ってboostのerror codeに変換 出来てるとはとても思えないんですけど。 もとのOpenSSLだとSSL_shutdown(3)の返り値は3つで、1と0と-1が あります。 このうち再度SSL_shutdown(3)を呼び出さないといけないのは、 双方向shutdownの場合に0が返ってきた時だけです。 あと、BIOがnon-blockingの場合は、-1かな(manには返り値の値が 書いていませんでした)が返ってきたときにSSL_get_errorをして、 SSL_ERROR_WANT_READもしくはWRITEがセットされていたときは、 READやWRITEをしてBIOの中身を空にしないといけません。 boostはその辺の処理をしているようにはとても見えないんですよね。 SSL_shutdown(3)を呼んで、error codeをコピーしてるだけ。asyncだと handlerを呼んでるだけ。 ひょっとして返り値が0のときを正常として、1とか-1のときに 適当に1とかに該当するシステムエラーのenumを返してるだけなんじゃないでしょうか。 # SSL_shutdownの場合、正常終了の返り値は1なんですが・・・ boost/asio/error.hpp の中にenum ssl_errosというのもありますが、 中身空っぽだし。 なので、該当事象でtry_againがecにセットされるとき、ちゃんと 双方向shutdownで先にclose notifyを送った状態で、相手からの close notifyを待つ状態にあたるのかどうかを確認すべきだと 思います。 それ以外の状態でtry_againがセットされているのなら、 sleepを入れようがasync_shutdownにしようが、解決には ならないです。 # だからboost/asioのSSL使うのは嫌なんだ・・・ (2014/10/08 15:53), Hiroaki Nakano wrote: > 中野@幕張です。 > > man 3 SSL_shudwonを見ていると、以下の記述がありました。 > > ------ > RETURN VALUES > The following return values can occur: > > ...(snip) > > 3. -1 > > The shutdown was not successful because a fatal error occurred either > at the protocol level or a connection failure occurred. It > can also occur if action is need to continue the operation for non-blocking BIOs. > Call SSL_get_error(3) with the return value ret to find out the reason. > ------ > > ということは、まだBIOの中にデータが残っているうちにshutdownが走っちゃいましたかね。 > > しかしBIOの中に残した状態を再現するとなると、難しくて思いつかない・・・ > > boost的にはBIO_writeしたあとなんで処理は終わってるんだけど、 > libsslの内部にあるBIOバッファからkernelのsocketシステムコールにはデータを > 書き込めてない状態でSSL_shutdownが走らないといけないんだよね。 > > 環境だけで作るのむずい。 > > (2014/10/07 17:11), Hiroaki Nakano wrote: >> 中野です。 >> おつです。 >> >> なかなか再現環境が組めないですorz >> 発見者はどんな環境で発生したんでしょう。。。 >> >> up_thread_client_disconnectが呼ばれているところを >> ピックアップしてみました。 >> >> 呼び出し箇所: >> up_thread_run >>  接続失敗時(L861) >> up_thread_client_accept_fail_event >>  handshake_error_codeがtry_againじゃないとき(L1233) >> up_thread_client_receive >>  recv_size<=0のとき(L1354) >>  ecがあってeofのとき(L1358) >>  ecがあってeofじゃなくてtry_againじゃないとき(L1379) >> down_thread_client_disconnect >>  正常ルート冒頭(L3186) >> up_thread_client_handle_async_read_some >>  errorがあってtry_againじゃないとき(L3711, L3713) >> >> このあたりが発生しそうな環境を作ったらいけるかな? >> 単純に高負荷掛けただけじゃ再現できませんでした。 >> >> 似たような事例を探してたら、TomcatのwriteのEAGAINでやっぱ >> AGAINループになってたみたいです。 >> https://issues.apache.org/bugzilla/show_bug.cgi?id=52856 >> >> こいつは対処でsleep入れてるなぁ・・・ >> >> 引き続き再現方法を探してみます。 >> >> (2014/10/02 19:15), Hibari Michiro wrote: >>> 雲雀です。 >>> >>> v3.1.2のリリースですが、 >>> もう一か所 直したい箇所があるので少々お待ちください。 >>> >>> その直したい箇所についてはチケット#34416で起票しました。 >>> https://sourceforge.jp/ticket/browse.php?group_id=1951&tid=34416 >>> >>> 以上、取り急ぎ。 >>> (2014/10/01 16:15), Hiroaki Nakano wrote: >>>> 中野@幕張です。 >>>> >>>> コミュニティリーダーからストップかかったので >>>> リリース遅らせます。 >>>> すみません。 >>>> >>>> 詳細は別途。 >>>> >>>> (2014/10/01 15:52), Hiroaki Nakano wrote: >>>>> 中野@幕張です。 >>>>> こんにちは。 >>>>> >>>>> とくに反応ないのでリリースしますね。 >>>>> >>>>> >>>>> (2014/09/18 14:08), Hiroaki Nakano wrote: >>>>>> 中野@幕張です。 >>>>>> こんにちは。 >>>>>> >>>>>> (2014/09/12 17:16), Hibari Michiro wrote: >>>>>>> 中野様 >>>>>>> >>>>>>> 雲雀です。 >>>>>>> お世話になっております。 >>>>>>> >>>>>>> v3.1.2-1のアップロードありがとうございました。 >>>>>>> 手元環境でざっと動作させてみたところ、 >>>>>>> 問題なく動作しているようでした。 >>>>>>> >>>>>>>>> 不具合等なかった場合、リリース前に太田さんに個別に >>>>>>>>> 連絡して、事象が直っているか確認を取ろうと思います。 >>>>>>> >>>>>>> そうですね。 >>>>>>> 何のため、太田様にもtmpに上げている >>>>>>> バイナリを共有し、事象が改善されたか >>>>>>> 確認していただくのが良いと思います。 >>>>>> >>>>>> 確認していただきました。事象が解消されたとのことです。 >>>>>> >>>>>> ということで、このバイナリをそのままv3.1.2-1として >>>>>> リリースしたいと思うのですが、いいでしょうか。 >>>>>> >>>>>> あと、gitツリーのmasterのHEADに、v3.1.2-1のタグを設定する >>>>>> つもりです。 >>>>>> >>>>>> # 個人的都合で、来週〜29日まで中野がrpmビルド環境を使えない >>>>>> # ので、明日か、それを過ぎたら10月になります。 >>>>>> >>>>>> >>>>>>> 以上、宜しくお願い致します。 >>>>>>> >>>>>>> (2014/09/11 11:33), Hiroaki Nakano wrote: >>>>>>>> UM-L7 開発者のみなさん >>>>>>>> >>>>>>>> 中野@幕張です。 >>>>>>>> こんにちは。 >>>>>>>> >>>>>>>> users MLで太田さんからご指摘のあった >>>>>>>> v3.1.0リリースで#30300がデグレードした件について、 >>>>>>>> 再度#30300の修正を入れなおしたv3.1.2-1版の >>>>>>>> x86_64 rpmバイナリを以下に置きました。 >>>>>>>> >>>>>>>> http://ultramonkey-l7.sourceforge.jp/_tmp/tmp_uml7_3_1_2-1 >>>>>>>> >>>>>>>> 不具合等無いか、ご確認ください。 >>>>>>>> >>>>>>>> 不具合等なかった場合、リリース前に太田さんに個別に >>>>>>>> 連絡して、事象が直っているか確認を取ろうと思います。 >>>>>>>> >>>>>>>> そのうえで、リリースという流れでいいでしょうか。 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > -- 中野 宏朗 (NAKANO Hiroaki)