Есть сервер на нем есть один из сервисов к которому каждую секунду кто то может 
подключиться , тоесть стандартный спринг-контроллер он вызывет сервис и тот обрщаеться к БД, ничего не обычного, проект клиента обращаетсяк сервису по формату JSON тоже все страндартно, Но проблема возникла в том что у сервака
кончаються ресурсы(кластер мы сделаем, но чуть позже), рестарт все лечит, но вопрос как эту нехватку 
ресурсов отлавливать? Пока я запускаю wget(наверно лучше curl) и если ответ больше 2секунд, то шлю алерт, пока клиеты у меня под контролем я их просто отключаю, потом такое станет не возможным , 
Есть что нибудь более стандартное/кошерное?  не я же один с такой ситуайией сталкиваюсь, 
 Я также могу также написать свой фильрт и по фй пи клиента либо давать ему данный либо слать нафиг, в предыдушем проекте больше 50запросов в час слали нафиг , велосипед изобретать не хочу , какие тут вырианты ? 

1. Инспекция кода на предмет незакрытых ресурсов, хранения ссылок на неипользуемые объекты и проч... Просто так ресурсы не исчезают, GC не может выполнить свою работу.
2. Профилировщик можно попробовать натравить
3. Нагрузочное тестирование провести
В общем искать косяк в коде, кластер тут не поможет судя по всему.
Хотя проблема то не раскрыта на 100% потому весь предыдущий пост - мысли вслух

Это сообщение отредактировал(а) d_k - 24.11.2015, 08:19

косяк видимо при эксепшене когда 
коннестион к базе падает, на это и логер намекает, но чем искать контретно ? 

Ну и что конекшин к базе? Пул настроен (опция validationQuery)? что логгер намекает?

вот это 

-------------------
22-Nov-2015 18:22:38.493 INFO [Thread-3] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["http-apr-8080"]
22-Nov-2015 18:22:38.556 INFO [Thread-3] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["ajp-apr-8009"]
22-Nov-2015 18:22:38.618 INFO [Thread-3] org.apache.catalina.core.StandardService.stopInternal Stopping service Catalina
22-Nov-2015 18:22:38.634 WARNING [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [GameService] appears to have started a thread named [Abandoned connection cleanup thread] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 java.lang.Object.wait(Native Method)
 java.lang.ref.ReferenceQueue.remove(Unknown Source)
 com.mysql.jdbc.AbandonedConnectionCleanupThread.run(AbandonedConnectionCleanupThread.java:43)
22-Nov-2015 18:22:38.634 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [GameService] created a ThreadLocal with key of type [org.sql2o.reflection.MethodAccessorsGenerator$1] (value [org.sql2o.reflection.MethodAccessorsGenerator$1@7e704d7]) and a value of type [sun.reflect.MethodAccessorGenerator] (value [sun.reflect.MethodAccessorGenerator@1f59dd32]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
22-Nov-2015 18:22:38.634 SEVERE [localhost-startStop-2] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [GameService] created a ThreadLocal with key of type [org.sql2o.reflection.MethodAccessorsGenerator$1] (value [org.sql2o.reflection.MethodAccessorsGenerator$1@7e704d7]) and a value of type [sun.reflect.MethodAccessorGenerator] (value [sun.reflect.MethodAccessorGenerator@4eaa7038]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
22-Nov-2015 18:22:38.665 INFO [Thread-3] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-apr-8080"]
22-Nov-2015 18:22:38.759 INFO [Thread-3] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["ajp-apr-8009"]
22-Nov-2015 18:22:38.821 INFO [Thread-3] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["http-apr-8080"]
22-Nov-2015 18:22:38.821 INFO [Thread-3] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["ajp-apr-8009"]
22-Nov-2015 18:26:19.595 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version:        Apache Tomcat/8.0.23
22-Nov-2015 18:26:19.596 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built:          May 19 2015 14:58:38 UTC
22-Nov-2015 18:26:19.596 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number:         8.0.23.0
22-Nov-2015 18:26:19.597 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name:               Windows 8.1
22-Nov-2015 18:26:19.597 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version:            6.3
22-Nov-2015 18:26:19.597 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture:          amd64
22-Nov-2015 18:26:19.597 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home:             E:\java\jre1.8.0_25
----------------------------

GameService  название проекта, org.sql2o - фраймворк  http://www.sql2o.org/

Пулл в context.xml    <Resource auth="Container" driverClassName="com.mysql.jdbc.Driver" maxActive="100" maxIdle="30" maxWait="10000" 
        name="jdbc/gamesData"  password="mypassword" type="javax.sql.DataSource" url="jdbc:mysql://192.168.1.xxx:3306/gamesData" username="myuser"/>


validationQuery Могу добавить что оно даст? 

Нет в этом логе ничего такого сверхестественного. Тут упоминается mem leakage при редеплое или стопе сервака при неудачной попытке или ее отсутсвии дерегистрировтаь драйвер jdbc.
Если несколько раз передеплаивать приложение - то реально можно заработать утечку.  Сам такое зарабатывал. Как лечить - вариант вручную дерегистрировать драйвер  jdbc в servlet context листенере.
Если конечно проблема именно в этой утечке...

что конкретно нужно делать? 

Нужно создать класс и зарегистрировать его в web.xml:




Этот ответ добавлен с нового Винграда - http://vingrad.com