Резюме. Это не баг. Это фича. То есть - дней через 10 (или 1000, я не
посчитал), оно бы развисло и пошло дальше.
Причина - не в TLS. Причина - в Вашем RFC822 Filter. У Вас там имеется
фильтр типа *4*.15*28*1993* - а CGatePro обрабатывает такие вещи очень
неэффективно.
Очень больших проблем эта неэффективность не вызывала, но замедление
пропорционально размеру строки в степени кол-ва '*' в шаблоне.
В том gcore, который вы прислали - была строка размером в 50 килобайт. И жевал он ее очень долго. То есть вырезанная из coredump такая же строка, засунутая в тест - жевалась явно более получаса (больше терпения не хватило).
Алгоритм обработки этих "*" изменен, в 4.1b3 будет новый - а пока попробуйте уменьшить кол-во шаблонов в которых "много" звездочек.
On Fri, 28 Mar 2003 00:01:41 -0800
Vladimir A. Butenko <vladimir_butenko@stalker.com> wrote:
> Похоже, что он зациклился где-то в TLS (а может - еще где) - другого
> об"яснения пока нету.
>
> Если он все еще в таком состоянии, и система отконфигурирована так, что
> при падении CGServer сделает coredump, то:
> а) поставить в Settings->General: Crash Recovery ->Disabled.
> b) послать CGatePro сигнал SIGABRT, чтобы он упал, сгенерив coredump.
>
> Если это получится, то назвать coredump CGServer-4.0.6-FreeBSD-izhnet.ru,
> за gzip-ить, загрузить на ftp.stalker.com и сообщить на
> cgp-support@stalker.com
>
>
> On Fri, 28 Mar 2003 10:42:48 +0400
> "Vladimir Zarozhevsky" <vladimir@izhnet.ru> wrote:
> >
> >
> > Привет!
> >
Sincerely,
Vladimir
Получено Tue Apr 01 09:08:29 2003
Этот архив был сгенерирован hypermail 2.1.8 : Fri 24 Apr 2015 - 16:12:34 MSK