― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 27 件の記事 ]  ページ移動 1つ前へ  1, 2
作成者 メッセージ
投稿記事Posted: 2011年1月04日(火) 19:51 
ありゃ、前の投稿みるとフォルダをクリックした時間が
書いてないから、netstatの出力が微妙な感じに見えるなぁ。
3つのアカウントの受信トレイをクリックしたのは 09:32:50 頃です。

確認コマンドの結果:
コード:
# thunderbird 起動直後
# (実 imapサーバ名は imap4.mail.vip.gq1.yahoo.com -> imap.mail.vip.sk1.yahoo.com に変動)
09:23:01
tcp        0      0 my.pc:33917 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33918 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33919 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)

# 一つ目の CLOSE_WAIT
09:25:10
tcp        0      0 my.pc:33917 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33918 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33919 imap4.mail.vip.gq:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)

# 3アカウント全部 CLOSE_WAIT
09:26:08
tcp        0      0 my.pc:33917 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33918 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:33919 imap4.mail.vip.gq:imaps CLOSE_WAIT  5075/icedove-bin off (0.00/0/0)

# 09:32:50 頃に 3つのアカウントの受信トレイをクリック
# CLOSE_WAITだった接続が消えて別の imapサーバに接続している。
09:33:00
tcp        0      0 my.pc:42861 imap.mail.vip.sk1:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:42863 imap.mail.vip.sk1:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)
tcp        0      0 my.pc:42862 imap.mail.vip.sk1:imaps ESTABLISHED 5075/icedove-bin off (0.00/0/0)


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月05日(水) 13:12 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
役に立つかどうかわかりませんが、今後のアドバイスを受けるための予備知識としてログの取り方を説明しておきます。ログを出力すればnetstatと併せて見る必要が無いかもしれません。

環境変数に以下を設定します。
NSPR_LOG_FILE=ログ出力ファイル
NSPR_LOG_MODULES=IMAP:1,timestamp

これでThunderbirdを起動するとログが書き出されます。
以下の例はアイ・オー・データ機器のルータのバグによりソフトバンクのimapサーバに接続できない状況でのログで、ログ出力レベルは1です。この例では接続を開始して約20秒後にソケットをクローズしてアボートメッセージになっています。
コード:
2011-01-05 03:36:38.895000 UTC - 0[1e28140]: 4aa6000:imap.softbank.jp:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2011-01-05 03:36:38.896000 UTC - 5804[5fcf9c0]: 4aa6000:imap.softbank.jp:NA:ProcessCurrentURL: entering
2011-01-05 03:36:38.896000 UTC - 5804[5fcf9c0]: 4aa6000:imap.softbank.jp:NA:ProcessCurrentURL:imap://XX_USER_XX@imap.softbank.jp:143/select%3E/Special:  = currentUrl
2011-01-05 03:36:59.921000 UTC - 5804[5fcf9c0]: 4aa6000:imap.softbank.jp:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 804b000e
2011-01-05 03:36:59.926000 UTC - 5804[5fcf9c0]: 4aa6000:imap.softbank.jp:NA:TellThreadToDie: close socket connection
2011-01-05 03:36:59.926000 UTC - 5804[5fcf9c0]: 4aa6000:imap.softbank.jp:NA:CreateNewLineFromSocket: (null)
2011-01-05 03:36:59.938000 UTC - 5804[5fcf9c0]: 4aa6000:imap.softbank.jp:NA:ProcessCurrentURL: aborting queued urls

ログにはパスワードは表示されないような気がしますがユーザIDは表示されるのでフォーラムで提示する場合は注意してください。
ログ出力レベルを4とか5にすると詳細に出力されて大量のログが吐き出されます。
ちなみに Gmailのアカウントでフォルダをいくつか移動した場合、ログレベル5では45MBのファイルになりました。メッセージのフェッチがログに吐かれるのでメッセージ数分のログが吐かれるんですね。

ログ出力についての詳細はGoogleなどで、NSPR_LOG_MODULES を検索すると(Firefoxのも有りますが)日本語や英語でたくさん出てきます。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月05日(水) 22:26 
kiyo4_k さんが書きました:
環境変数に以下を設定します。
NSPR_LOG_FILE=ログ出力ファイル
NSPR_LOG_MODULES=IMAP:1,timestamp

これでThunderbirdを起動するとログが書き出されます。

ありがとうございます。せっかく教えていただいたので、
検索して出てきた下記 URLを参考にしつつ、ログをとって眺めてみました。
結論からいうと、怪しそうな部分があったので、
libnspr(になるのかな?)の動作に詳しい方の協力がいただければと思います。

参考 URL:
 MailNews:Logging - MozillaWiki
  https://wiki.mozilla.org/MailNews:Logging
 HTTP Logging - MDC Doc Center
  https://developer.mozilla.org/ja/HTTP_Logging
  https://developer.mozilla.org/en/HTTP_Logging
 NSPR Reference: Chapter 26 Logging
  http://www.mozilla.org/projects/nspr/reference/html/prlog.html
 TBTracer :: Versions :: Add-ons for Thunderbird
  https://addons.mozilla.org/ja/thunderbird/addon/175992/
 ※TBTracerは、便利そうなものがあるんだなぁ、と思っていれてみましたが、
  nsHostResolver、nsSocketTransportに対応してないみたいで、
  今回は今ひとつ役に立ちませんでした。


設定した環境変数:
コード:
NSPR_LOG_MODULES=imap:2,nsHostResolver:4,nsSocketTransport:4,timestamp
NSPR_LOG_FILE=/path/to/log/icedove-nspr.log


総接続数 50に達した場合、常に出るというわけではないですが、
"imap.mail.yahoo.com のアドレス解決をしています"
みたいなメッセージがステータスバーに出ることが多いような気がしたので、
imap の動作にたどり着けてない可能性があると推測し、
nsHostResolver:4,nsSocketTransport:4を追加してみました。

総接続数 50に達した後に新規フォルダをクリックすると出力されるログ
コード:
2011-01-05 12:58:47.459717 UTC - -1233168592[b6517060]: a1976000:imap.mail.yahoo.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2011-01-05 12:58:47.466503 UTC - -1342420112[a18099d0]: a1976000:imap.mail.yahoo.com:NA:ProcessCurrentURL: entering
2011-01-05 12:58:47.466548 UTC - -1342420112[a18099d0]: a1976000:imap.mail.yahoo.com:NA:ProcessCurrentURL:imap://my%2Eaccount%40ymail%2Ecom@imap.mail.yahoo.com:993/select%3E/INBOX:  = currentUrl


この後にこのアカウントに関連すると思われる imap モジュール? のログは出力されませんでした。
※上記だと "a1976000"(何かのハンドラ?)で判断。

それで、総接続数 50に達した以降、下記みたいなログが延々繰り返されるのですが、
1行目の"calling PR_Poll [active=40 idle=10]" の activeとidle足したら 50になるのが
総接続数 50と合致して、とても怪しく見えます。
かつ、この後のログが、
 CLOSE_WAITな接続の合計数が 12 -> active=38 idle=12
 CLOSE_WAITな接続の合計数が 16 -> active=34 idle=16
のように、idle の値と CLOSE_WAITな接続の合計数が同じ値で遷移しつつ繰り返されて、
ますます怪しいです。

この active と idle を足した値が 50 を超えられないのは何故か、
どこで判断、設定されているのか、また 50に達した場合の動作が意図されたとおりのものなのか、
という辺りがわかれば、今回の現象は解決するのかなぁ、と考えています。

このあたりの動作、制限値などについて、どなたか詳しい方はおられないでしょうか?


PR_Poll
http://www.mozilla.org/projects/nspr/re ... html#19653
↑とか見てみましたが、これ以上追っかけられませんでした。

コード:
2011-01-05 12:58:47.585415 UTC - -1251095696[b6517690]:   calling PR_Poll [active=38 idle=12]
2011-01-05 12:58:47.585427 UTC - -1251095696[b6517690]: poll timeout: 65535
2011-01-05 12:58:47.585439 UTC - -1251095696[b6517690]:     timeout = 0 milliseconds
2011-01-05 12:58:47.585548 UTC - -1251095696[b6517690]:     ...returned after 0 milliseconds
2011-01-05 12:58:47.585569 UTC - -1251095696[b6517690]: STS poll iter [0]
2011-01-05 12:58:47.585581 UTC - -1251095696[b6517690]:   active [37] { handler=a1f96d00 condition=0 pollflags=5 }
2011-01-05 12:58:47.585594 UTC - -1251095696[b6517690]:   active [36] { handler=a1798bc0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585606 UTC - -1251095696[b6517690]:   active [35] { handler=a1f957a0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585619 UTC - -1251095696[b6517690]:   active [34] { handler=a179a710 condition=0 pollflags=5 }
2011-01-05 12:58:47.585631 UTC - -1251095696[b6517690]:   active [33] { handler=a1f95670 condition=0 pollflags=5 }
2011-01-05 12:58:47.585643 UTC - -1251095696[b6517690]:   active [32] { handler=a1f94700 condition=0 pollflags=5 }
2011-01-05 12:58:47.585655 UTC - -1251095696[b6517690]:   active [31] { handler=a1f94f50 condition=0 pollflags=5 }
2011-01-05 12:58:47.585667 UTC - -1251095696[b6517690]:   active [30] { handler=a1f94bc0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585698 UTC - -1251095696[b6517690]:   active [29] { handler=a1f95410 condition=0 pollflags=5 }
2011-01-05 12:58:47.585712 UTC - -1251095696[b6517690]:   active [28] { handler=a1799670 condition=0 pollflags=5 }
2011-01-05 12:58:47.585724 UTC - -1251095696[b6517690]:   active [27] { handler=a4f5df60 condition=0 pollflags=5 }
2011-01-05 12:58:47.585736 UTC - -1251095696[b6517690]:   active [26] { handler=a179a970 condition=0 pollflags=5 }
2011-01-05 12:58:47.585748 UTC - -1251095696[b6517690]:   active [25] { handler=a179bda0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585760 UTC - -1251095696[b6517690]:   active [24] { handler=a17997a0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585773 UTC - -1251095696[b6517690]:   active [23] { handler=a1f958d0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585785 UTC - -1251095696[b6517690]:   active [22] { handler=a1f95ff0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585797 UTC - -1251095696[b6517690]:   active [21] { handler=a179b7b0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585809 UTC - -1251095696[b6517690]:   active [20] { handler=a1798110 condition=0 pollflags=5 }
2011-01-05 12:58:47.585821 UTC - -1251095696[b6517690]:   active [19] { handler=a179bb40 condition=0 pollflags=5 }
2011-01-05 12:58:47.585833 UTC - -1251095696[b6517690]:   active [18] { handler=a1f94370 condition=0 pollflags=5 }
2011-01-05 12:58:47.585845 UTC - -1251095696[b6517690]:   active [17] { handler=a1799410 condition=0 pollflags=5 }
2011-01-05 12:58:47.585857 UTC - -1251095696[b6517690]:   active [16] { handler=a179a4b0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585870 UTC - -1251095696[b6517690]:   active [15] { handler=a1799d90 condition=0 pollflags=5 }
2011-01-05 12:58:47.585882 UTC - -1251095696[b6517690]:   active [14] { handler=a1799b30 condition=0 pollflags=5 }
2011-01-05 12:58:47.585894 UTC - -1251095696[b6517690]:   active [13] { handler=a1799ff0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585915 UTC - -1251095696[b6517690]:   active [12] { handler=a17991b0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585929 UTC - -1251095696[b6517690]:   active [11] { handler=a1798a90 condition=0 pollflags=5 }
2011-01-05 12:58:47.585942 UTC - -1251095696[b6517690]:   active [10] { handler=a1f97a10 condition=0 pollflags=5 }
2011-01-05 12:58:47.585954 UTC - -1251095696[b6517690]:   active [9] { handler=a1798830 condition=0 pollflags=5 }
2011-01-05 12:58:47.585966 UTC - -1251095696[b6517690]:   active [8] { handler=a1798700 condition=0 pollflags=5 }
2011-01-05 12:58:47.585978 UTC - -1251095696[b6517690]:   active [7] { handler=a17985d0 condition=0 pollflags=5 }
2011-01-05 12:58:47.585990 UTC - -1251095696[b6517690]:   active [6] { handler=a17984a0 condition=0 pollflags=5 }
2011-01-05 12:58:47.586003 UTC - -1251095696[b6517690]:   active [5] { handler=a1798960 condition=0 pollflags=5 }
2011-01-05 12:58:47.586015 UTC - -1251095696[b6517690]:   active [4] { handler=a1f94110 condition=0 pollflags=5 }
2011-01-05 12:58:47.586027 UTC - -1251095696[b6517690]:   active [3] { handler=a179ad00 condition=0 pollflags=5 }
2011-01-05 12:58:47.586039 UTC - -1251095696[b6517690]:   active [2] { handler=a179ae30 condition=0 pollflags=5 }
2011-01-05 12:58:47.586052 UTC - -1251095696[b6517690]:   active [1] { handler=a4f5dd00 condition=0 pollflags=5 }
2011-01-05 12:58:47.586064 UTC - -1251095696[b6517690]:   active [0] { handler=a4f5e090 condition=0 pollflags=5 }
2011-01-05 12:58:47.586076 UTC - -1251095696[b6517690]:   idle [11] { handler=a1f95a00 condition=0 pollflags=0 }
2011-01-05 12:58:47.586088 UTC - -1251095696[b6517690]:   idle [10] { handler=a1f94830 condition=0 pollflags=0 }
2011-01-05 12:58:47.586101 UTC - -1251095696[b6517690]:   idle [9] { handler=a1f945d0 condition=0 pollflags=0 }
2011-01-05 12:58:47.586113 UTC - -1251095696[b6517690]:   idle [8] { handler=a17998d0 condition=0 pollflags=0 }
2011-01-05 12:58:47.586125 UTC - -1251095696[b6517690]:   idle [7] { handler=a179ba10 condition=0 pollflags=0 }
2011-01-05 12:58:47.586140 UTC - -1251095696[b6517690]:   idle [6] { handler=a1f952e0 condition=0 pollflags=0 }
2011-01-05 12:58:47.586169 UTC - -1251095696[b6517690]:   idle [5] { handler=a1f972f0 condition=0 pollflags=0 }
2011-01-05 12:58:47.586183 UTC - -1251095696[b6517690]:   idle [4] { handler=a179b550 condition=0 pollflags=0 }
2011-01-05 12:58:47.586195 UTC - -1251095696[b6517690]:   idle [3] { handler=a1f964b0 condition=0 pollflags=0 }
2011-01-05 12:58:47.586207 UTC - -1251095696[b6517690]:   idle [2] { handler=a1f95d90 condition=0 pollflags=0 }
2011-01-05 12:58:47.586219 UTC - -1251095696[b6517690]:   idle [1] { handler=a4f5de30 condition=0 pollflags=0 }
2011-01-05 12:58:47.586231 UTC - -1251095696[b6517690]:   idle [0] { handler=a4f5c080 condition=0 pollflags=0 }


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月06日(木) 04:46 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
私からのヒントだけのような情報から英語のサイトをご覧になってパラメータを選んで試してみて問題点を絞られるというのは嬉しいです。

whoami さんが書きました:
総接続数 50に達した場合、常に出るというわけではないですが、
"imap.mail.yahoo.com のアドレス解決をしています"
みたいなメッセージがステータスバーに出ることが多いような気がしたので、
imap の動作にたどり着けてない可能性があると推測し、
nsHostResolver:4,nsSocketTransport:4を追加してみました。

総接続数 50に達した後に新規フォルダをクリックすると出力されるログ
コード:
2011-01-05 12:58:47.459717 UTC - -1233168592[b6517060]: a1976000:imap.mail.yahoo.com:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
2011-01-05 12:58:47.466503 UTC - -1342420112[a18099d0]: a1976000:imap.mail.yahoo.com:NA:ProcessCurrentURL: entering
2011-01-05 12:58:47.466548 UTC - -1342420112[a18099d0]: a1976000:imap.mail.yahoo.com:NA:ProcessCurrentURL:imap://my%2Eaccount%40ymail%2Ecom@imap.mail.yahoo.com:993/select%3E/INBOX:  = currentUrl
このあたり、私と同じような感じですね。TellThreadToDie は出なくて50になるように新たな接続を開始しているということでしょうか。

ちなみに、私のログの内容の場合はアイ・オー・データ機器の「WN-G54/R3」というルータなんですが、たぶんバグで繋がらないんです。このルータは以前にもAppleのサイトにDNSでアドレス解決が出来ないバグが有ってファームをアップデートした実績があります。
最大接続数に制限があるルータやネットワーク機器を介しているということは有りませんか?
もしくは同じようなアイ・オー・データ機器のルータを使用しているとか....(-_-;)

DebianはわからないですがWindows XPのTCPIP.SYSとかではセッション数に50という制限が有ったり、ネットワークドライバに制限有りという記述も見かけます。Linux系でもドライバなどWindows用を兼用しているものがあるということが有ったんですが、どうなんでしょうかね。

ルータなどネットワーク機器を介してるなら単独でネットに繋いで試してみるとか、いかがでしょう。


whoami さんが書きました:
この後にこのアカウントに関連すると思われる imap モジュール? のログは出力されませんでした。
※上記だと "a1976000"(何かのハンドラ?)で判断。
これってスレッドIDじゃないんでしょうか。


whoami さんが書きました:
それで、総接続数 50に達した以降、下記みたいなログが延々繰り返されるのですが、
1行目の"calling PR_Poll [active=40 idle=10]" の activeとidle足したら 50になるのが
総接続数 50と合致して、とても怪しく見えます。



このあたりの動作、制限値などについて、どなたか詳しい方はおられないでしょうか?


PR_Poll
http://www.mozilla.org/projects/nspr/re ... html#19653
↑とか見てみましたが、これ以上追っかけられませんでした。
なるほど。Thunderbirdはポーリングに値するイベントの場合は自分で管理用のテーブルを生成してポーリングするんですね。それがアイドルと足して50が上限になっているってことでしょうか。
ということは、通常なら50で足りるはずだと想定されているんでしょうかね。
私の場合はポーリングするに値しないからタイムアウトで終わってしまうってことですね。


通常ならポーリング管理用のテーブルは50で足りるはずということなら、なぜ繋がらないか...というところでしょうか。
50という数字は接続時のイベントの結果から自動で得られる数値なのか、とか。
もしそうなら私としては自分の状況からルータなどの機器が怪しいような気がします (-_-;)

# 私もYahoo!のimapのメールアカウントを持っていれば比べられるんですけど...


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月06日(木) 16:58 
kiyo4_k さんが書きました:
私からのヒントだけのような情報から英語のサイトをご覧になってパラメータを選んで試してみて問題点を絞られるというのは嬉しいです。

そう言っていただけると私も試し甲斐があります。
それに、自分ひとりでは絶対にこんなところまで確認できなかったので、
kiyo4_kさんの助言には本当に感謝しています。

kiyo4_k さんが書きました:
このルータは以前にもAppleのサイトにDNSでアドレス解決が出来ないバグが有ってファームをアップデートした実績があります。

どんなロジックでそんなことが起こりうるのか想像もつきませんが、
アイ・オー・データのルータは避けたほうが無難そうなことはわかりました。

kiyo4_k さんが書きました:
もしそうなら私としては自分の状況からルータなどの危機が怪しいような気がします (-_-;)

ルータは NECアクセステクニカの WR8300Nです。
http://121ware.com/product/atermstation ... index.html

もし、ルータを疑うとなると debian/linux で firewall(iptables) の設定を
しなければならなくなるので、ちょっと時間がかかってしまいます。
※素っ裸でネット接続はちょっと怖いです。


それで、ルータのバグでないことを確認する方法がないか少し考えてみました。

現状での反証:
 ・特定の imapサーバのみで現象が発生するわけではない。
  ※imap.aol.com, imap.mail.yahoo.comでの発生を確認
 ・imap 接続のみで発生するわけではない。
  ※総接続数 50になると、tb上での http接続もできなくなる(接続先は Yahoo, AOL以外)。
   具体的には、html メールの画像が読み込まれない。
 ・総接続数 50になった状態で、firefoxでの Web閲覧には何の支障もない。
  ※Yahoo、AOLの WebMailも閲覧可能。
 ・総接続数 50になった状態でも、imap.googlemail.com、imap.mail.yahoo.comは pingを返す。
  ※imap.aol.comはもともと pingを返してくれない。


上記だけでも、ルータのバグとしての可能性はないような気がしますが、
特定サイトのアドレス解決ができないなんてことがありえるということなら、
どんなバグでもありえそうなので、ルータのバグの線も可能性としては残ります。
いやそれにしても、うーん、特定サイトのアドレス解決ができないって
ルータ側が原因でありえるのかって感じですが...

ともかくも、あと何がネックになっているか考えると、「総接続数 50の制限」です。
これが tbに閉じた制限であることを確認する方法がないかと考えて、
別プロファイル、別プロセスで tbを追加起動してみるというのを思いつきました。

下記手順で、2つの tb プロセスの総接続数が 50を超えられることが確認できたので、
少なくとも
 ・ルータに「imap接続の上限が 50」のような制限がないこと
 ・NICドライバに「セッション数の上限が 50」のような制限がないこと
  ※NICはオンボードの Realtek RTL8111Dで、ドライバは kernel 2.6.32.27に含まれるr8169.ko
は証明できたと思います。

とするとやはり tb というか、libnsprに閉じた問題である可能性が非常に高いと思います。
推測としては、「総接続数 50」な場合の「CLOSE_WAITな接続」を終了する部分の
ロジックに何らかの不具合があるということになるでしょうか。
ただ、kiyo4_kさんが、50以上の接続を確認している以上、バグと仮定するなら
linux platform上の tbのバグってことになる、のかなぁ...?
linux上に限られたバグならこれまでに似たような現象がほとんど報告されてないのも
納得いかなくもない? うーむ。


確認手順:
 1. debian上で 新規ユーザ "test"を作成。
 2. testユーザ環境で、tbの新規プロファイル作成、imap.mail.yahoo.comのアカウントをいくつか設定。
 3. chown でユーザ権限を現ユーザのものに変更
 4. 現ユーザ環境で、総接続数 50の状況にする。
 5. 現ユーザ環境で、下記コマンドで tbを追加起動。Yahooアカウントに接続
   HOME=/home/test icedove -no-remote &
 6. 2つの tb プロセスの総接続数が 50を超えていることを確認。
   $ netstat -tpn | grep 993.*icedove | wc -l
   58

kiyo4_k さんが書きました:
# 私もYahoo!のimapのメールアカウントを持っていれば比べられるんですけど...

Yahoo UKで Free Accountを作成すれば、Yahoo USとは微妙に体制が違うらしく
何もしなくても imap、pop3が使えます。(thunderbird 3.1.xでの自動設定で imapを選択可能)
試してませんが、今なら USのアカウントでも imap が使えるようになってるはずです。
Yahoo JPはたぶんどっちも使えないのかな。
ちなみに、AOLも Free Accountで imap、pop3が使えます。
http://www.yahoo.co.uk/
http://www.aol.jp/
http://www.aol.com/


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月07日(金) 05:51 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
今日は時間がないので結果だけ

Yahoo UKでフォルダを51個と元から出来た3個のフォルダが有り、
mail.server.serverXX.max_cached_connections=60に設定して順番に移動しただけです。
接続は50を超えていて、54だったか、もっと多かったような気がします。
全部接続中のようで、ログにはThunderbirdを終了した時点でcloseやlogoutがまとめて吐かれています。

mail.server.serverXX.max_cached_connections=5のときはcloseやlogoutは無しで5接続しか有りませんでした。これはポートREUSEのような感じです。

Windows版はmax=50を超えることが出来て、ずっと放っておけば順番にサーバから接続が切られているという感じです。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月07日(金) 15:15 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
whoami さんが書きました:
いやそれにしても、うーん、特定サイトのアドレス解決ができないって
ルータ側が原因でありえるのかって感じですが...
http://www.iodata.jp/lib/product/w/1800_winvista.htmのWN-G54/R3 ファームウェアのほうの「変更履歴」に書かれています。
DHCPのプログラムのバグでしょうか。ソフトバンクのimapに繋がらないのも他は繋がるしルータの電源を入れ直しで繋がるのでバグだと思っています。
製品名でGoogle検索するとボロカスに書かれている記事も見つかります。地元のメーカで知り合いも居るし直接文句を言っても良いんですけど...

whoami さんが書きました:
とするとやはり tb というか、libnsprに閉じた問題である可能性が非常に高いと思います。
推測としては、「総接続数 50」な場合の「CLOSE_WAITな接続」を終了する部分の
ロジックに何らかの不具合があるということになるでしょうか。
ただ、kiyo4_kさんが、50以上の接続を確認している以上、バグと仮定するなら
linux platform上の tbのバグってことになる、のかなぁ...?
linux上に限られたバグならこれまでに似たような現象がほとんど報告されてないのも
納得いかなくもない? うーむ。
Linux版ユーザが少ないか、これでimapをガンガン使っている人が居ないとか...

whoami さんが書きました:
Yahoo UKで Free Accountを作成すれば、Yahoo USとは微妙に体制が違うらしく
何もしなくても imap、pop3が使えます。(thunderbird 3.1.xでの自動設定で imapを選択可能)
簡単にアカウントを取れてimapを使えました。
前の記事に書いたようにWindows版は50を超えて同時に接続しているみたいですね。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月07日(金) 21:00 
kiyo4_k さんが書きました:
Windows版はmax=50を超えることが出来て、ずっと放っておけば順番にサーバから接続が切られているという感じです。

確認ありがとうございます。

こちらでも、すこしだけ追加の確認をしてみました。

debian/squeezeの thunderbird(icedove)は、別パッケージになっている libnspr/libnssを
動的にリンクするようになっています。
これを、thunderbirdに含まれる libnspr/libnssを使用するようにリビルドして
確認してみましたが、状況は変わらずでした。

ソースコードの動作を追っかけるようなことはできませんが、
なんとなく nsprのソースを眺めたりすると、当たり前といえば当たり前ですが
platform、 architectureでの定義と分岐の嵐です。
本来的には動作の違いを吸収するための定義と分岐なのでしょうが、
逆から見れば、それだけ動作の違いを発生させうる箇所が存在しているって
ことですよね。
そう考えると linux、windowsでの動作の違いもありうるのかなぁ、
とか思ってしまいます。

どちらにしろ、こちらでできることは尽きた感じですね。


kiyo4_k さんが書きました:
Linux版ユーザが少ないか、これでimapをガンガン使っている人が居ないとか...

なんか、それがすべてって感じがします。

最近は ubuntu人気でユーザが増えてるらしいので、linux上の thunderbirdユーザも
それなりにいるはずですが、通常の用途って考えると 3アカウント x 8フォルダくらいなら
24接続で十分足りてしまいますよね。
いやでも、5アカウント x 10フォルダで 50接続なら結構ありそうだなぁ、うーん。
私自身も普段使用する分にはあまり困ってないし、
「ずっと起動してるとなんか重くなるから時々再起動」みたいな感じで、
気づきにくいのかも。
うーん、今んとこ現象発生確認数 「1」ってことかぁ...

それにしても、linuxに限らず 「thunderbird 全体での最大同時接続数」って、
FAQとかで非常にありそうなんだけど、どこにもないのがやっぱり不思議だなぁ...


kiyo4_k さんが書きました:
WN-G54/R3 ファームウェアのほうの「変更履歴」に書かれています。

検索してみると、確かに当時は阿鼻叫喚っぽい感じだったんですね。
そんなバグを仕込めるアイ・オー・データもある意味すごいというかなんというか...
文句を言って直るものなら言ったほうがいいでしょうけど、
そんな変なバグが出る製品って基本的な設計が何か間違っていて、
金も人も技術力もない開発だと根本的な再設計なんてできるはずもないから、
延々同じような変なバグに悩まされるってことになりがちです。
※もし知り合いの方が開発職でしたら申し訳ありません。
 でももしそうなら、悲惨すぎる内情の面白い話が聞けるかもしれません。
私は別系統の製品で経験しました。
それ以来、そんなことでイラつくのは嫌なのでとっとと買い換えることにしています。
けど、1万円以下のルータで安定していて不具合のないものってほとんど無いんですよね。
良さそうなの見つけても何かが足りなかったりして。
WR8300Nを買うときも相当悩みました。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月09日(日) 05:18 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
whoami さんが書きました:
なんとなく nsprのソースを眺めたりすると、当たり前といえば当たり前ですが
platform、 architectureでの定義と分岐の嵐です。
本来的には動作の違いを吸収するための定義と分岐なのでしょうが、
逆から見れば、それだけ動作の違いを発生させうる箇所が存在しているって
ことですよね。
そう考えると linux、windowsでの動作の違いもありうるのかなぁ、
とか思ってしまいます。
Unix系とWindowsとはソケットコマンドのリターンが違ったり応答の確認や切断までの手順とか微妙に違ったりするので(WinSockもバージョンで違いますが)、Unix系とWindowsの両方をサポートするソースはグチャグチャでしょうね。

whoami さんが書きました:
それにしても、linuxに限らず 「thunderbird 全体での最大同時接続数」って、
FAQとかで非常にありそうなんだけど、どこにもないのがやっぱり不思議だなぁ...
英語が達者ならBugzillaで聞いてみるのも手かもしれません。私は立ち入らない領域なんですが...


しょうがないので未解決で「情報求む」のまま、Unix系でのimapユーザのアドバイス待ち状態にしておきます。


whoami さんが書きました:
kiyo4_k さんが書きました:
WN-G54/R3 ファームウェアのほうの「変更履歴」に書かれています。

検索してみると、確かに当時は阿鼻叫喚っぽい感じだったんですね。
そうみたいですね。私は先日Googleで検索するまで知りませんでした。
創業以前から知っていますが創業時はそれなりの技術力や企画力は有ったと思います。私は地元の別のメーカが好きですけど。同じメモリメーカーでしたが今は何を作っているのかわかりません。
知り合いは多いですが....まぁ、悪口は書きません。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月09日(日) 18:13 
kiyo4_k さんが書きました:
しょうがないので未解決で「情報求む」のまま、Unix系でのimapユーザのアドバイス待ち状態にしておきます。

「情報求む」のにあたって、現象を再現する方法を少し詳しく書き出してみました
再現/確認方法などへのつっこみもお待ちしています。


今回の現象について、自分以外の Linux環境で現象発生が確認されていないため、
どなたか Linux環境での再現テストにご協力いただけないでしょうか
もちろん、今回の現象に関する動作などに詳しい方の協力も歓迎します。

確認していただきたいのは、以下の 4 項目です。
 ・下記「現象再現方法」の 5、6「Thunderbird 全体での最大同時接続数」
 ・下記「現象再現方法」の 7「新規接続遅延の確認」
 ・Linux Distribution Name/Version
 ・Thunderbird Version/User Agent

また、以下内容について情報をお持ちの方の協力もお待ちしています。
 ・Linux版 Thunderbird 全体での最大同時接続数が 50というのは正しいのか?
 ・Linux版 Thunderbird 全体での最大同時接続数を増やすための設定方法
  ※ about:config やコンパイル時設定など
 ・他のプラットフォームでは、Thunderbird 全体での最大同時接続数に制限があるのか?
  あるとすればその制限値と制限値の設定方法


現象:
 ・Linux版 Thunderbirdでは、総接続数が 50を超えることができない
 ・Linux版 Thunderbird全体での総接続数が 50に達すると
  imap.mail.yahoo.com、imap.aol.comで新規接続が数分から 20分程度待たされる
  ※imap.googlemail.comでは待たされない

Thunderbirdの imap 接続時の動作: (状況、ログ確認からの推定)
 ・imap フォルダの閲覧時、1フォルダにつき 1接続となる
  ※メールが含まれない空フォルダでも 1接続となる
 ・アカウントに設定されている「サーバへの最大同時接続数」を超えた場合は、
  古い接続を切断して新規接続を行う


現象再現方法:
 1. Thunderbird上の全アカウントの imap フォルダ数合計が 51以上(60くらい)になるように設定
   各 imapアカウント上にフォルダを合計で 51以上作成。空フォルダで問題ありません。
   「test」フォルダの下に「01」から「30」までの数字でフォルダ作成のような感じで
   1つのフォルダ配下に多数のフォルダを作成すれば削除するのが簡単でいいかもしれません。

 2. 個々のアカウントで作成したフォルダ数以上の値を「サーバへの最大同時接続数」に設定する
  2.1 「サーバへの最大同時接続数」設定方法
   1. メニューから「編集」 -> 「アカウント設定」を開く
   2. 当該アカウント配下のサーバ設定を選択
   3. 「サーバ設定」カテゴリの下の方にある「終了時にごみ箱を空にする」の右側にある「詳細」ボタン押下
   4. 「サーバへの最大同時接続数」を作成したフォルダ数以上の値に設定
  2.2 もしくは、about:configで 当該 imapサーバの
  「mail.server.serverXX.max_cached_connections」の値を作成したフォルダ数と同じ数にする

 3. 念の為 Thunderbirdを再起動

 4. imap フォルダを 51以上閲覧する
  単にフォルダペインの各フォルダを順に選択していくだけです。

 5. netstatで 接続数を確認
 
コード:
netstat -tpn | grep -e "icedove\|thunderbird" | wc -l

  総接続数が 50だった場合は 7へ。
  総接続数が 51以上だった場合は 6へ。

 6. 総接続数が 51以上だった場合
  ※総接続数以外の制限にひっかかりそうですが、可能なら試してみてください。
  1 に戻ってフォルダ数合計を、100、200、300と増やして試してみる。
  netstatでの接続数確認で一定値以上値が増えたくなった時点での接続数を確認。
  Thunderbird 全体での最大同時接続数が確認できたら 7へ。

 7. 新規接続遅延の確認
  5 または 6 で確認した「Thunderbird 全体での最大同時接続数」上限の接続を
  維持した状態で、Yahooか AOLのアカウントのフォルダをいくつか選択してみた時に、
  マウスカーソルが数分以上 busy状態になるか確認。
  もし、gmail、Yahoo、AOL、以外の imap アカウントを持っている場合は、
  そのアカウントのフォルダ閲覧時にマウスカーソルが数分以上 busy状態になるか確認。


単なる技術的な興味としてですが、Windows上でも今回の現象と同様の制限が
あるのではないかと考えています。
Windows版 Thunderbirdでの確認にご協力いただける場合、
 2 の「編集」メニューは、「ツール」メニューです。
 5 の netstatの代わりに TCPViewを使用することで確認可能です。
TCPView for Windows
http://technet.microsoft.com/ja-jp/sysi ... s/bb897437
また、Windowsにも netstatがあったような気がしますが、
細かいオプションが異なる点に留意してください。


少し話がそれるのかもしれませんが、今回の件での検索中にひっかかった
下記 URLを見ると、フリーアカウントで imapを提供しているプロバイダも結構あるようです。

Comparison of webmail providers
http://en.wikipedia.org/wiki/Comparison ... _providers



kiyo4_k さんが書きました:
英語が達者ならBugzillaで聞いてみるのも手かもしれません。私は立ち入らない領域なんですが...

外国語圏のソフトを使用する上での壁ですよね。Bugzillaは少し頭にありましたが、
シンプルな質問に限定したとしても、結局 Linux版、Windows版と広がっていきそうで、
今回の件を英語で説明する自信はまったくないので諦めました。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2011年1月23日(日) 14:16 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
Windows版ではWindows 7(Enterprize)以外での情報も歓迎します。

_________________
Administratorより投稿される皆さんへお願い:
・質問には、あなたの使用している製品名だけでなく、そのバージョンおよびOSの種類を明示してください。
フォーラムの利用に関するご案内をご一読下さい。 トピック投稿用テンプレートもご利用下さい。
・また、問題が解決した場合や入手したい情報が得られた場合は、解決した旨の返信をお願いします。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2011年1月24日(月) 22:18 
オフライン
Administrator

登録日時: 2005年9月02日(金) 00:59
記事: 1762
whoami さんが書きました:
kiyo4_k さんが書きました:
英語が達者ならBugzillaで聞いてみるのも手かもしれません。私は立ち入らない領域なんですが...

外国語圏のソフトを使用する上での壁ですよね。Bugzillaは少し頭にありましたが、
シンプルな質問に限定したとしても、結局 Linux版、Windows版と広がっていきそうで、
今回の件を英語で説明する自信はまったくないので諦めました。
日本語で、ということなら
Bugzilla.jp http://bugzilla.mozilla.gr.jp/
とか
Bugzilla-ja https://developer.mozilla.org/ja/Bugzilla-ja
が有ります。でも、どちらがアクティブでどちらに今回必要なスキルの持ち主が多いのか、どちらに製品への影響力があるのか、あるいは双方の仲が良いのか悪いのか私には見当もつきません。(元々はもじら組のBugzilla.jpが元になっています)
双方にupされている内容を見て判断してみてください。


通報する
ページトップ
 プロフィール  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 27 件の記事 ]  ページ移動 1つ前へ  1, 2

All times are UTC + 9 hours


オンラインデータ

このフォーラムを閲覧中のユーザー: なし & ゲスト[55人]


トピック投稿:  可
返信投稿:  可
記事編集: 不可
記事削除: 不可
ファイル添付: 不可

検索:
ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean