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

Windows版ではWindows 7(Enterprize)以外での情報も歓迎します。

[quote="kiyo4_k"]しょうがないので未解決で「情報求む」のまま、Unix系でのimapユーザのアドバイス待ち状態にしておきます。 [/quote]
「情報求む」のにあたって、現象を再現する方法を少し詳しく書き出してみました
再現/確認方法などへのつっこみもお待ちしています。


今回の現象について、自分以外の 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で 接続数を確認
　[code]netstat -tpn | grep -e "icedove\|thunderbird" | wc -l[/code]
　　総接続数が 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/sysinternals/bb897437
また、Windowsにも netstatがあったような気がしますが、
細かいオプションが異なる点に留意してください。


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

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



[quote="kiyo4_k"]英語が達者ならBugzillaで聞いてみるのも手かもしれません。私は立ち入らない領域なんですが．．．[/quote]
外国語圏のソフトを使用する上での壁ですよね。Bugzillaは少し頭にありましたが、
シンプルな質問に限定したとしても、結局 Linux版、Windows版と広がっていきそうで、
今回の件を英語で説明する自信はまったくないので諦めました。

[quote="whoami"]なんとなく nsprのソースを眺めたりすると、当たり前といえば当たり前ですが
platform、 architectureでの定義と分岐の嵐です。
本来的には動作の違いを吸収するための定義と分岐なのでしょうが、
逆から見れば、それだけ動作の違いを発生させうる箇所が存在しているって
ことですよね。
そう考えると linux、windowsでの動作の違いもありうるのかなぁ、
とか思ってしまいます。[/quote]Unix系とWindowsとはソケットコマンドのリターンが違ったり応答の確認や切断までの手順とか微妙に違ったりするので（WinSockもバージョンで違いますが）、Unix系とWindowsの両方をサポートするソースはグチャグチャでしょうね。

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


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


[quote="whoami"][quote="kiyo4_k"]WN-G54/R3 ファームウェアのほうの「変更履歴」に書かれています。 [/quote]
検索してみると、確かに当時は阿鼻叫喚っぽい感じだったんですね。[/quote]そうみたいですね。私は先日Googleで検索するまで知りませんでした。
創業以前から知っていますが創業時はそれなりの技術力や企画力は有ったと思います。私は地元の別のメーカが好きですけど。同じメモリメーカーでしたが今は何を作っているのかわかりません。
知り合いは多いですが．．．．まぁ、悪口は書きません。

[quote="kiyo4_k"]Windows版はmax=50を超えることが出来て、ずっと放っておけば順番にサーバから接続が切られているという感じです。[/quote]
確認ありがとうございます。

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

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

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

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


[quote="kiyo4_k"]Linux版ユーザが少ないか、これでimapをガンガン使っている人が居ないとか．．．[/quote]
なんか、それがすべてって感じがします。

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

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


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

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

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

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

今日は時間がないので結果だけ

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を超えることが出来て、ずっと放っておけば順番にサーバから接続が切られているという感じです。

[quote="kiyo4_k"]私からのヒントだけのような情報から英語のサイトをご覧になってパラメータを選んで試してみて問題点を絞られるというのは嬉しいです。[/quote]
そう言っていただけると私も試し甲斐があります。
それに、自分ひとりでは絶対にこんなところまで確認できなかったので、
kiyo4_kさんの助言には本当に感謝しています。

[quote="kiyo4_k"]このルータは以前にもAppleのサイトにDNSでアドレス解決が出来ないバグが有ってファームをアップデートした実績があります。[/quote]
どんなロジックでそんなことが起こりうるのか想像もつきませんが、
アイ・オー・データのルータは避けたほうが無難そうなことはわかりました。

[quote="kiyo4_k"]もしそうなら私としては自分の状況からルータなどの危機が怪しいような気がします　(-_-;)[/quote]
ルータは NECアクセステクニカの WR8300Nです。
http://121ware.com/product/atermstation/product/warpstar/wr8300n/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

[quote="kiyo4_k"]＃ 私もYahoo!のimapのメールアカウントを持っていれば比べられるんですけど．．．[/quote]
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/

私からのヒントだけのような情報から英語のサイトをご覧になってパラメータを選んで試してみて問題点を絞られるというのは嬉しいです。

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

総接続数 50に達した後に新規フォルダをクリックすると出力されるログ
[code]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[/code][/quote]このあたり、私と同じような感じですね。TellThreadToDie は出なくて50になるように新たな接続を開始しているということでしょうか。

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

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

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


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


[quote="whoami"]それで、総接続数 50に達した以降、下記みたいなログが延々繰り返されるのですが、
1行目の"calling PR_Poll [active=40 idle=10]" の activeとidle足したら 50になるのが
総接続数 50と合致して、とても怪しく見えます。
：
：
：
このあたりの動作、制限値などについて、どなたか詳しい方はおられないでしょうか?


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


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

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

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

これでThunderbirdを起動するとログが書き出されます。[/quote]
ありがとうございます。せっかく教えていただいたので、
検索して出てきた下記 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に対応してないみたいで、
　　今回は今ひとつ役に立ちませんでした。


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

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

総接続数 50に達した後に新規フォルダをクリックすると出力されるログ
[code]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[/code]

この後にこのアカウントに関連すると思われる 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/reference/html/priofnc.html#19653
↑とか見てみましたが、これ以上追っかけられませんでした。

[code]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 }[/code]

役に立つかどうかわかりませんが、今後のアドバイスを受けるための予備知識としてログの取り方を説明しておきます。ログを出力すればnetstatと併せて見る必要が無いかもしれません。

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

これでThunderbirdを起動するとログが書き出されます。
以下の例はアイ・オー・データ機器のルータのバグによりソフトバンクのimapサーバに接続できない状況でのログで、ログ出力レベルは1です。この例では接続を開始して約20秒後にソケットをクローズしてアボートメッセージになっています。
[code]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[/code]
ログにはパスワードは表示されないような気がしますがユーザIDは表示されるのでフォーラムで提示する場合は注意してください。
ログ出力レベルを4とか5にすると詳細に出力されて大量のログが吐き出されます。
ちなみに Gmailのアカウントでフォルダをいくつか移動した場合、ログレベル5では45MBのファイルになりました。メッセージのフェッチがログに吐かれるのでメッセージ数分のログが吐かれるんですね。

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

ありゃ、前の投稿みるとフォルダをクリックした時間が
書いてないから、netstatの出力が微妙な感じに見えるなぁ。
3つのアカウントの受信トレイをクリックしたのは 09:32:50 頃です。

確認コマンドの結果:
[code]# 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)
[/code]

[quote="kiyo4_k"]変更可能なパラメータで言うと
network.http.keep-alive.timeout
mail.server.serverXX.timeout
mailnews.tcptimeout
ぐらいが関係有るのか無いのか、ですかね。[/quote]


えー、ちょっと間があいてしまいましたが、mailnews.tcptimeout、
network.http.keep-alive.timeoutの設定について追加で確認してみました。
mail.server.serverXX.timeoutについては、すべての値が 29だったので、
デフォルト値の情報が見つからなかったこともあり(デフォルト値を
知らないままでの変更はちょっと怖い)、特に値を変更しての確認はしていません。
全体の結論としては、特に進展もなく、細かい可能性を少しつぶしたという感じです。


確認したこと:
　下記設定にした場合に現象に改善がみられるかどうか
　　mailnews.tcptimeout=10 (default 100)
結果: 変化なし

確認したこと:
　下記設定にした場合に現象に改善がみられるかどうか
　　network.http.keep-alive.timeout=10 (default 115)
結果: 変化なし

確認したこと:
　下記設定にした場合に現象に改善がみられるかどうか
　　network.http.keep-alive.timeout=10 (default 115)
　　mailnews.tcptimeout=10 (default 100)
結果: 変化なし



念の為というか、↓についても疑問に思ったので試してみました。

確認したこと:
　下記の状況の時に新規接続が可能かどうか
　　・thunderbird全体での総接続数が 50以下
　　・アカウントの最大同時接続数に達する
　　・アカウントのサーバへの接続がすべて CLOSE_WAITになる
　　※Yahooで確認。AOLも確認しようとしましたが、20分以上たっても
　　　CLOSE_WAITに遷移しなかったので諦めました。

結果: CLOSE_WAITの状態になっても、新規接続は可能。

疑問/推測:
・Yahooの imapサーバとの接続は 2分から3分の間に imap サーバ側から切断されるらしい。
・timerになにも出てこないってことは、keepaliveとか有効になってない?
・この動作なら、thunderbird全体での総接続数が 50の場合でも
　できてもよさそうなんだけどなぁ...

確認内容詳細:
　3つの yahoo アカウントに下記を設定
　・「新着メッセージがないか起動時に確認する」にチェック
　　　※ mail.server.serverXX.check_new_mail=true

　すべての yahoo アカウントに下記を設定
　・「新着メッセージがないか起動時に確認する」のチェックをはずす
　　　※ 上記 3つの yahoo アカウント以外でということ
　　　※ mail.server.serverXX.check_new_mail=false
　・「新着メッセージがないかXX分ごとに確認する」にチェック、値はすべて 30分以上
　　　※ mail.server.serverXX.check_time=30
　・「サーバへの最大同時接続数」を "1"に変更
　　　※ mail.server.serverXX.max_cached_connections=1
　・「サーバがサポートしていれば IDLE コマンドを使う」のチェックをはずす
　　　※ Yahooは imap idleに対応していない
　　　※ この設定の about:configでの項目がわかりませんでした。

確認コマンド:
[code]while pgrep icedove-bin 2>/dev/null
do date "+%H:%M:%S"
LC_ALL=C netstat -top 2>/dev/null | grep imap.*mail.*imaps.*icedove-bin
sleep 5
done | tee -a /path/to/log/netstat.log
[/code]


確認コマンドの結果:
[code]# 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: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)
[/code]


とりあえず自分にやれそうなことは尽きた感じです。
えー、ネットワーク関係に詳しいわけではないので、おかしなことをしているかもしれませんが、
可能な限りの情報提供ということでお許しください。
変な点などへのつっこみもお待ちしています。

[quote="whoami"]ありゃ、もしかしてこれ、↓[quote="whoami"]となると問題は、「長期間 CLOSE_WAITな状態」になってしまう AOLとYahooに
対して設定で回避可能か、可能ならばその設定値は?、というところですか。[/quote]は早とちりの可能性があるってことですか?
えーと、thunderbirdの imap クライアントとしての実装が RFC違反の
gmailを前提にしているために、まともに RFC準拠の実装しているであろう
AOL、Yahooで不具合となっている可能性があるということですよね。
んー、mail.server.serverXX.is_gmailみたいな設定もあるからなんとなく安心してたんですが。[/quote]GmailにはRFC違反が有るらしいんですが、４年も前のことでsmtpに限ってだったかimapもだったかよく覚えていないんですけど、動作とIPの接続状態を見ていてなんとなく これも同じ状況でAOL、Yahooでバグが発症しているのかなぁなんて思いました。
IP接続の状態を見ていると、Gmailの場合はどんどん切断と接続を繰り返していて速すぎて見えないのか、または同じ接続を再利用しているような表示に見えます。Thunderbirdでフォルダを移動するときに、「接続しています」とか表示されているのにIP接続の状態表示が変化せずに進んでいくので そんな風に感じるんです。
でも、見た目だけではわかんないんですけどね。

.is_gmailなんてパラメータが有るんですね、なにに使うんだろう．．．


結局、
Gmailは問題ないが、AOL、Yahooで接続状態が長時間残ったままで新しい接続が待たされてしまい、順次接続が切断されるまでフォルダ移動が出来なくなってしまう。
mail.server.serverXX.max_cached_connections=1 にしても接続状態が残ったままなので意味が無い。
mail.server.serverXX.max_cached_connections と
mail.imap.max_cached_connections の値をいくら大きくしても最大で50を超えないので、50以上の接続となるアカウント数での利用では同じことになる。

解決策として、
接続数を50以上に増やす方法か、
AOL、Yahooで接続状態が長時間残ったままにならない方法を知りたい。

ということで
Thunderbirdのimapの動作に詳しい方からの応援を待ちましょう。
どなたかお願いします。

[quote="kiyo4_k"]GmailがQUITの後に応答を返さずに接続を切断してしまうというRFC違反のバグが有って、
Thunderbirdは このようなRFC違反の動作をリカバーするように作られているような気がするからです。[/quote]
[quote="kiyo4_k"]「Thunderbirdは相手の切断を待ち続けるだけ」ですかね。これ、ちょっと痛いですね。 [/quote]

ありゃ、もしかしてこれ、↓
[quote="kiyo4_k"]となると問題は、「長期間 CLOSE_WAITな状態」になってしまう AOLとYahooに
対して設定で回避可能か、可能ならばその設定値は?、というところですか。[/quote]
は早とちりの可能性があるってことですか?
えーと、thunderbirdの imap クライアントとしての実装が RFC違反の
gmailを前提にしているために、まともに RFC準拠の実装しているであろう
AOL、Yahooで不具合となっている可能性があるということですよね。
んー、mail.server.serverXX.is_gmailみたいな設定もあるからなんとなく安心してたんですが。


[quote="kiyo4_k"]あら？　同じでしたか．．．[/quote]
ちょっとあせって確認、投稿しちゃったところがあるので、少し補足します。

全アカウントの mail.server.serverXX.max_cached_connections=1 にした時の
確認方法ですが、全アカウント合計が 30くらいで、最大同時接続数が 50なので、
当然、最大同時接続数に足りないので、あちこちで html メールを開いて
最大同時接続数にしました。
ただ、httpの方が接続確立->切断までの時間が短いので、確認結果に少し不安は残ります。
「AOL行けたっ」と思ったら、最大同時接続数以下になってたみたいなことはあったので。

あと、厳密な割合まではわかりませんが、傾向として Yahooの方が
CLOSE_WAITで残りやすい感触です。
Yahooは imap idleサポートしてなくて、AOLはサポートしてるのが
関係あるのか、ないのか...


[quote="kiyo4_k"]う～ん．．．．Gmailで問題ないのに、他のimapで問題が発生するっていうのは、
ThunderbirdのimapってGmailに特化してるんですかね。[/quote]

今回ほど詳しく確認したわけじゃないけど、前に会社で courier imapサーバ使用してた
時期があって、特に問題なく使用してたんですけどねぇ...

[quote="kiyo4_k"]ここまでくると内部動作に詳しい人の応援が必要な感じです。[/quote]
確かにどなたかにご登場いただけるとありがたいですが、
現状、あまり切羽詰っているわけでもないので、教えていただいたパラメータを
試したりしながら気長にやろうと思います。

今日はもう終りにしようと思いますが、なにか進展があれば書き込みますので
またよろしくお願いします。ありがとうございました。