ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / jetty, EndPoint и потоки
3 сообщений из 3, страница 1 из 1
jetty, EndPoint и потоки
    #38928286
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
Добрый день!

Есть SOAP-сервис (jetty 9.2.1.v20140609, javax.xml.ws.Endpoint).
Его дёргают из другого приложения. Хорошо дёргают.
В некоторый момент он начинает сыпать сообщениями, что не может создать поток для ответа.
Код: sql
1.
2.
3.
4.
2015-04-05/07:07:24.167/MSK WARN  pool-1-thread-3-selector-ServerConnectorManager@1bb6c5fd/2 io.SelectorManager - Could not process key for channel java.nio.channels.SocketChannel[connected local=/10.
216.98.110:8080 remote=/10.216.32.35:60084]
java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)


 
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
        at java.lang.Thread.start(Thread.java:714)
        at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
        at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
        at org.eclipse.jetty.http.spi.DelegatingThreadPool.execute(DelegatingThreadPool.java:64)
        at org.eclipse.jetty.io.AbstractConnection$FillingState.onEnter(AbstractConnection.java:373)
        at org.eclipse.jetty.io.AbstractConnection.next(AbstractConnection.java:267)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:557)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:82)
        at org.eclipse.jetty.io.SelectChannelEndPoint.onSelected(SelectChannelEndPoint.java:109)
        at org.eclipse.jetty.io.SelectorManager$ManagedSelector.processKey(SelectorManager.java:572)
        at org.eclipse.jetty.io.SelectorManager$ManagedSelector.select(SelectorManager.java:543)
        at org.eclipse.jetty.io.SelectorManager$ManagedSelector.run(SelectorManager.java:485)
        at org.eclipse.jetty.util.thread.NonBlockingThread.run(NonBlockingThread.java:52)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)




При этом не падает (т.е. даже дампа нет).
Подсоединится к нему не могу .
В этот момент процесс отжирает 8Гб (из 16).

При этом все запросы логируются и они выполняются на другой машинке спокойно, занимая не более 300Мб (т.е. утечек нет).

Есть подозрение, что клиент некорректно выполняет SOAP запрос, не закрывая его (или закрывая, но через несколько минут). В результате чего у сервера заканчивается память (ответы большие, по несколько килобайт, а то и десятков).

Вот вопросы.

1. Возможен ли такой сценарий?

2. Если клиент не поправят, то что можно сделать нам? Дать больше памяти на сишный хип? Как?

3. А то может просто jetty обновить? 9.2.11 уже... Точнее обновлю, раз уж заглянул, вопрос в том, поможет ли. Сервер живёт 3 дня где-то, и каждое падение- куча нервов...

 
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
 java -XX:+PrintFlagsFinal -version | grep -iE 'HeapSize|PermSize|ThreadStackSize'
    uintx AdaptivePermSizeWeight                    = 20              {product}           
     intx CompilerThreadStackSize                   = 0               {pd product}        
    uintx ErgoHeapSizeLimit                         = 0               {product}           
    uintx HeapSizePerGCThread                       = 87241520        {product}           
    uintx InitialHeapSize                          := 261349568       {product}           
    uintx LargePageHeapSizeThreshold                = 134217728       {product}           
    uintx MaxHeapSize                              := 4181721088      {product}           
    uintx MaxPermSize                               = 174063616       {pd product}        
    uintx PermSize                                  = 21757952        {pd product}        
     intx ThreadStackSize                           = 1024            {pd product}        
     intx VMThreadStackSize                         = 1024            {pd product}


--
Алексей.
...
Рейтинг: 0 / 0
06.04.2015, 16:29
| Ответить | Цитировать | Написать  
jetty, EndPoint и потоки
    #38928303
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Ошибка java.lang.OutOfMemoryError: unable to create new native thread совсем не обязательно связана с памятью.
На сколько я знаю, существует две распространенные причины:
1) Нехватка нативной памяти. Процесс на уровне ОС ограничен в использовании памяти. Большую часть отожрала куча. Но стэк потока не находится в куче. Он создаётся вне кучи. Возможно нативная память уже забита, и как результат - ошибка.
2) Лимиты пользователя - достаточно стандартная фишка в linux - уперлись в какой-нибудь ulimit и больше процессов (которые в линухе и являются потоками) пользователь создать не может.

Дамп потоков легко снимается из командной строки. Можно в него посмотреть чтобы определиться с вопросом, а не слишком ли много вышло потоков. Дамп кучи, по идее, тоже можно создать из командной строки, а потом скопировать на локальную машину для анализа. Но куча там не основная проблема.
...
Рейтинг: 0 / 0
06.04.2015, 16:41
| Ответить | Цитировать | Написать  
jetty, EndPoint и потоки
    #38929090
Alexey Tomin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Tomin
Участник
В общем- не в этом дело оказалось.
Логирования добавил- тормоза внезапно возникают в dbcp2+oracle
Т.е. запросы туда уходят, а результата нет вообще. Ну и потоки копятся, для новых запросов.

При этом пытаюсь поставить таймаут- и никак.

Т.е. DataSource создаю так:
 
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
        Properties props = new Properties();
        props.put("defaultQueryTimeout", queryTimeout);
        ConnectionFactory connectionFactory = new DriverManagerConnectionFactory(connectionString, props);
        PoolableConnectionFactory poolableConnectionFactory = new PoolableConnectionFactory(connectionFactory, null);
        poolableConnectionFactory.setDefaultQueryTimeout(queryTimeout);
        GenericObjectPool<PoolableConnection> connectionPool = new GenericObjectPool<>(poolableConnectionFactory);
        poolableConnectionFactory.setPool(connectionPool);
        PoolingDataSource<PoolableConnection> dataSource = new PoolingDataSource<>(connectionPool);



Потом получаю коннект
Код: java
1.
2.
    Connection con = dataSource.getConnection(); {
    PreparedStatement ps = con.prepareStatement(SQL);



При этом в отладке видно, что у con стоит нужный defaultQueryTimeout, но даже если дополнительно пишу
ps.setQueryTimeout(queryTimeout);
всё одно- запросы не обрубаются.

Как сделать так, чтобы слишком длинные запросы (где тормоза- я не знаю, у меня не появляются) обрубались?
Или через дочерний поток делать, а если долго- жёстко отрубать его? Кстати, как это правильно делать, т.е. чтобы через 10 секунд дочерний поток убивался 100% с освобождением ресурсов?
...
Рейтинг: 0 / 0
07.04.2015, 12:34
| Ответить | Цитировать | Написать  
3 сообщений из 3, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / jetty, EndPoint и потоки
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=38928303&tid=2125587]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 37ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 32ms
get tp. blocked users:
 1ms
others: 223ms
total:  329ms
созд. / загр.: 329ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]