Спустя три года с момента прошлого релиза представлена (http://mail-archives.apache.org/mod_mbox/perl-modperl/201102...) новая версия Apache-модуля mod_perl 2.0.5 (http://perl.apache.org/). Новая версия носит (http://perl.apache.org/dist/mod_perl-2.0-current/Changes) в основном корректирующий характер, исправляя накопившиеся ошибки и решая некоторые проблемы совместимости с будущей веткой Perl 5.14. В новой версии добавлена поддержка APR::Socket::fileno, обеспечен экспорт переменной окружения PROXYREQ_RESPONSE, налажен процесс сборки с использованием не поддерживающего многопоточность APR.Устранены потенциальные уязвимости, связанные с выходом за границы буфера в Apache2::RequestIO::read, возможностью загрузки сторонних библиотек через APR::XSLoader и Apache2::XSLoader, а также организацией XSS-атаки через запрос к Apache2::Status.
URL: http://mail-archives.apache.org/mod_mbox/perl-modperl/201102...
Новость: http://www.opennet.me/opennews/art.shtml?num=29539
Я год назад пытался прейти на второго апача, выяснил что если в конфе апача указать расположение модулей Perl по пути отличном от системного с помощью PerlSwitches, апач сходил с ума. Выжирал всю память при вервом же запросе и падал. Надеюсь эту фигню пофиксили. Ждем-с в портах фри свежий mod_perl2, а так пока тусим на под старым добрым другом апачем 1.3 и первым mod_perl. :)
Пользую PerlSwitches на апаче 2.2, работает как часы. Да и в рассылке такая бага не гуглится.Может быть дело в чём-то другом?
> Может быть дело в чём-то другом?Сейчас уже сложно сказать. Появится в портах 2.0.5 попробую повторить эксперимент. Сейчас уже и Perl другой юзаем 5.12. На тот момент был по-моему 5.10. В конфигурации особенного ничего нет, пара самописных модулей и все это под соусом HTML::Mason крутится.
А ругань была по типу: "Deep recursion on subroutine "Compress::Raw::Zlib::AUTOLOAD". Это я у себя в камментах на против опции PerlSwitches оставил на рабочей машине. Подробностей больше не осталось. При чем в наших модулях мы напрямую Zlib и не юзаем сами. Это либо в самом mod_perl касяк, либо в HTML::Mason где-то, либо еще в какой подключаемой либе используется.
Кстати, если не использовать данную опцию, а кинуть модули по системному пути, то все работало. Но на тот момент такой вариант не подошел.
Не знаю уж... разве еще не все перешли на FCGI или Plack? Или что-то типа HTTP::Server?
а этот переход дает какие-то серьезные преимущества в сравнении с mod_perl ?
Отказ от apache, например.
Да, отказ от толстого и прожорливого апача. :)
Очень смешно, mod_perl для того и нужен, чтобы все держать в памяти, чтобы максимуму быстро обслужить юзверя, не тратя время на подгрузку и компиляцию либ и прочую ерунду.
> Очень смешно, mod_perl для того и нужен, чтобы все держать в памяти,
> чтобы максимуму быстро обслужить юзверя, не тратя время на подгрузку и
> компиляцию либ и прочую ерунду.Однако он медленнее, чем FastCgi/Nginx.
>Однако он медленнее, чем FastCgi/Ngnix.В общем-то вопрос скорее религиозный и зависим от архитектуры веб-приложения, чем проблема в скорости. Ну и не забываем, что у mod_perl есть такие фичи, которых у FastCGI просто не может быть из-за разных подходов в работе. mod_perl позволяет лазить в самые кишки веб-сервера и вытворять всякие полезности на этапе обработки запроса. FastCGI это фактически классический CGI, но быстрее обычного.
http://kiev.pm.org/?q=node/424 - тут разжевано.