Привет всем!

Запускаю на томкате простой сервлет.
Вот часть его кода:

      protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
            response.getWriter().write("post!!!");
            response.setStatus(200);
      }

Используется чистый дистриб томката, скаченный с сайта. Конфиг используется стандартный, за исключением коннектора

    <Connector port="8443"
        maxHttpHeaderSize="8192"
        connectionTimeout="60000"
        enableLookups="false"
        disableUploadTimeout="true"

        maxThreads="900"
        minSpareThreads="350"
        maxSpareThreads="700"
        acceptCount="700"

        protocol="HTTP/1.1"
        SSLEnabled="true"
        scheme="https"
        secure="true"
        clientAuth="false"
        sslProtocol="TLS"
        keystoreFile="/opt/.keystore"
        keystorePass="tomcat" />

Система работает под нагрузкой следующего рода. 40 потоков, каждый из которых шлет раз в секунду POST запрос.
Никаких необычных заголовков в запросе нет.
Томкату при старте выдаю 300Мб памяти.

После примерно трех часов работы он выдает OutOfMemoryError.

Здравствуйте, Alex20010, Вы писали:

A>После примерно трех часов работы он выдает OutOfMemoryError.
Открой для себя профайлер или для особых любителей можно heap dump analyzer

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Alex20010, Вы писали:

A>>После примерно трех часов работы он выдает OutOfMemoryError.
B>Открой для себя профайлер или для особых любителей можно heap dump analyzer

Профайлер давно открыл. Анализ дампа показывает подозрительно большое количество инстансов com.sun.net.ssl.internal.ssl.SSLSessionImpl. Остальное вроде все в норме.

Здравствуйте, Alex20010, Вы писали:

A>Профайлер давно открыл. Анализ дампа показывает подозрительно большое количество инстансов com.sun.net.ssl.internal.ssl.SSLSessionImpl. Остальное вроде все в норме.

есть такая проблема у людей.. как то решают.. а детали к сожалению не написали

здесь

Здравствуйте, Alex20010, Вы писали:

A>Профайлер давно открыл. Анализ дампа показывает подозрительно большое количество инстансов com.sun.net.ssl.internal.ssl.SSLSessionImpl. Остальное вроде все в норме.
Какая версия JVM? Попробуй что-нибудь поновее.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Alex20010, Вы писали:

A>>Профайлер давно открыл. Анализ дампа показывает подозрительно большое количество инстансов com.sun.net.ssl.internal.ssl.SSLSessionImpl. Остальное вроде все в норме.
B>Какая версия JVM? Попробуй что-нибудь поновее.

Пробовал на последних JVM и Tomcat — та же ерунда.

JVM 1.6.06
Tomcat 6.0.16

Здравствуйте, Alex20010, Вы писали:

B>>Какая версия JVM? Попробуй что-нибудь поновее.
A>Пробовал на последних JVM и Tomcat — та же ерунда.
Sorry, прогнал. Не нашел с пол пинка реализацию SSLSessionImpl.

A>JVM 1.6.06
A>Tomcat 6.0.16
Возможно что в топике по ссылке правы. По какой-то причине финализатор в этом классе выкидывает исключение и объекты не собираются.

Здравствуйте, Vampiro, Вы писали:

A>>Профайлер давно открыл. Анализ дампа показывает подозрительно большое количество инстансов com.sun.net.ssl.internal.ssl.SSLSessionImpl. Остальное вроде все в норме.
V>есть такая проблема у людей.. как то решают.. а детали к сожалению не написали

V>здесь
Ну, там достаточно инфы чтобы копнуть в глубь дебагом. SSLSessionImpl при финализации вызывает SSLSessionBindingListener, в последнем происходит исключение, которое надо поймать и устранить. Исключение и приводит к лику.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Vampiro, Вы писали:

A>>>Профайлер давно открыл. Анализ дампа показывает подозрительно большое количество инстансов com.sun.net.ssl.internal.ssl.SSLSessionImpl. Остальное вроде все в норме.
V>>есть такая проблема у людей.. как то решают.. а детали к сожалению не написали

V>>здесь
B>Ну, там достаточно инфы чтобы копнуть в глубь дебагом. SSLSessionImpl при финализации вызывает SSLSessionBindingListener, в последнем происходит исключение, которое надо поймать и устранить. Исключение и приводит к лику.

Это первый вариант. Второй вариант использовать что-нибудь вместо JSSE. Может кто знает можно ли такое сделать в томкате. Знаю как использовать сертификат от openSSL, но вот как использовать реализацию openSSL . Надо ли пересобирать томкат? Кто делал подобное, подскажите где почитать...

B>>Ну, там достаточно инфы чтобы копнуть в глубь дебагом. SSLSessionImpl при финализации вызывает SSLSessionBindingListener, в последнем происходит исключение, которое надо поймать и устранить. Исключение и приводит к лику.

Кроме того как описано в ссылке дело может быть не в исключении, а просто в некорректной реализации метода valueUnbound и из него вызываемых, вызов которого просто где-то встает колом.

Здравствуйте, Alex20010, Вы писали:

A>Кроме того как описано в ссылке дело может быть не в исключении, а просто в некорректной реализации метода valueUnbound и из него вызываемых, вызов которого просто где-то встает колом.
Сомневаюсь. Это бы подвесило весь finalizer thread, тогда бы профайлер показал это на дампе потоков.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Alex20010, Вы писали:

A>>Кроме того как описано в ссылке дело может быть не в исключении, а просто в некорректной реализации метода valueUnbound и из него вызываемых, вызов которого просто где-то встает колом.
B>Сомневаюсь. Это бы подвесило весь finalizer thread, тогда бы профайлер показал это на дампе потоков.

Как можно заставить томкат работать по SSL без JSSE?

Здравствуйте, Alex20010, Вы писали:

A>Профайлер давно открыл.

оффтоп, но все равно полезно
я тут на днях открыл для себя интересный баг в JProfiler — нужно делать запись для памяти и cpu только после старта приложения (во время работы), а не устанавливать эти checkboxes автоматически при запуске.
Проверено на ConcurrentLinkedQueue: добавление и тут же удаление из очереди из нескольких потоков приводило к OOME — объекты ConcurrentLinkedQueue$Node не собирались GC.

Здравствуйте, Alex20010, Вы писали:

A>Как можно заставить томкат работать по SSL без JSSE?
Но проблема-то не совсем в нем.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Alex20010, Вы писали:

A>>Как можно заставить томкат работать по SSL без JSSE?
B>Но проблема-то не совсем в нем.

Проблема в реализации JSSE. Настройка томката на использование openSSL через APR ни к чему не привела. Все равно для чего-то используются классы JSSE и проблема повторяется.

Обертка метода finalize в try{}catch показала, что исключение там не стреляет, поэтому гипотеза, выдвигаемая здесь не подтверждается.

    public void finalize()
    {
        String as[] = getValueNames();
        for(int i = 0; i < as.length; i++)
            try {
                removeValue(as[i]);
            } catch (Throwable ex) {                                                            
                System.err.println("Error while finalizing session");
            }
    }

Здравствуйте, Alex20010, Вы писали:

A>Обертка метода finalize в try{}catch показала, что исключение там не стреляет, поэтому гипотеза, выдвигаемая здесь не подтверждается.

А профайлер не показывает кто же ссылается на эти экземпляры? Может тогда дамп хипа сделать и посмотреть?

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Alex20010, Вы писали:

A>>Обертка метода finalize в try{}catch показала, что исключение там не стреляет, поэтому гипотеза, выдвигаемая здесь не подтверждается.

B>А профайлер не показывает кто же ссылается на эти экземпляры? Может тогда дамп хипа сделать и посмотреть?

Конечно показывает. На эти экземпляры ссылается один из инстансов класса java.lang.ref.Finalizer.

Причем интересный факт. Я подложил свою сборку класса SSLSessionImpl и выяснилось, что на 100 вызовов конструкторов этого класса вызывается 10-15 finalize. Следовательно получается глюк в Finalizer...

Здравствуйте, Alex20010, Вы писали:

B>>А профайлер не показывает кто же ссылается на эти экземпляры? Может тогда дамп хипа сделать и посмотреть?
A>Конечно показывает. На эти экземпляры ссылается один из инстансов класса java.lang.ref.Finalizer.

http://www.javaperformancetuning.com/tools/jprofiler/index.shtml

Let's find out what these strange finalizer objects do. We add a filter step by selecting java.lang.ref.Finalizer, and choose the "Outgoing references" in the navigation panel. The result is shown in the first screenshot on the right. Since java.lang.ref.Finalizer is derived from java.lang.ref.Reference it has a referent field which holds the content of the weak reference. Consequently, we select this referent field and choose the "Classes" option in the navigation panel. As the second screenshot on the right shows, the overwhelming majority of weak references can be attributed to the javax.swing.text package

Через Finalizer таки можно попробовать найти кто удерживает объект.