BiTel

В логах постоянно проскакивают подобные сообщения:



Сами запросы могут быть разными. Иногда это запросы из моих скриптов, иногда - в коде разработчиков.
Причина - незакрытые PreparedStatement-ы.

Например, в данном случае:
ru.bitel.bgbilling.plugins.dispatch.server.dao.SubscriptionDao:

- забыли сделать ps.close();

Предлагаю писать в эту тему такие запросы с указанием версии.
Очевидно, свои косяки писать не надо

Итак:
Сервер: вер. 5.2 сборка 1309 от 08.10.2012 13:30:45
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.6.0_22
ru.bitel.bgbilling.plugins.dispatch вер. 5.2 сборка 44 от 01.10.2012 12:53:04


- второй точно должны поправить разработчики, а вот с первым - не факт.

Начал рыться в логах и исходниках - много запросов типа SELECT * FROM ...
Они вызываются в коде битела во всяких Dao (data access object), типа TariffOptionDao, ContractDao и т.п.
Закрываться такие preparedStatement-ы должны явно тем, кто использует этот Dao вызовом метода recycle():


Поэтому совет всем скриптописцам:
Используешь Dao - делай recycle()!
Я вот не знал, сейчас буду искать у себя по коду.

Сервер: вер. 5.2 сборка 1309 от 08.10.2012 13:30:45
dialup вер. 5.2 сборка 354 от 01.10.2012 12:52:48

Ещё несколько - 100% Бител:


- не закрыт ps в bitel.billing.server.contract.bean.PersonalTariffManager.getParentTreeTariffIds


- SessionTrafficCache.flushCache()


- FunctionManager.logFunctionProcess()

предлагаю закрепить тему вверху, очень частая ошибка которая проскакивает как в собственных скриптах, так как и оказалось у разрабов

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Исправлено. В следующем обновлении будет

Вообще у нас один герой нашел все такие места в 5.3 и исправил. Но мы боимся продукт его героических усилий накатить на 5.2, так слишком много изменений и вероятность ошибок очень велика.Лучше будем исправлять потихоньку , по запросу.

закрепите тему!!!

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Дополнительно хочу отметить, что это не совсем ошибка, а скорее предупреждение.
Statement все же закрывается при закрытии Connection, т.е. после окончания выполнения действия/задачи и т.п.
Но в отдельных случаях (обычно в задачах планировщика) может плохо влиять на производительность (из-за внутренней логики пула DBCP - например, если работать напрямую с mysql JDBC Connection, то все работает также быстро), а также при использовании serverPreparedStatement - количество открытых внутри mysql PreparedStatement'ов увеличивается, а оно обычно ограничено.

не знаю, сюда ли, но аккаунт сервер при старте вот такое выдает:

Исправлено . В следующем обновлении будет.

в последнем обновлении Inet у аккаунтинг сервера вот такое вываливается при старте

12-21/19:55:53 ERROR ["http-bio-/0.0.0.0-8080"-exec-5] DefaultServerSetup - Many statements was open at connection close:
com.mysql.jdbc.ServerPreparedStatement[3491] - (select t1.val, t1.cid from contract_parameter_type_2_log as t1 left join contract as t4 on t4.id=t1.cid left join address_city as t2 on t2.id=1 left join address_street as t3 on t3.id=15 where t1.pid=8 and (t1.val like concat('%',t2.title,'%') and t1.val like concat('%',t3.title,'%') and t1.val like '%Рґ. 1%')) union (select t1.address, t1.cid from contract_parameter_type_2 as t1 left join contract as t4 on t4.id=t1.cid left join address_city as t2 on t2.id=1 left join address_street as t3 on t3.id=15 where t1.pid=8 and (t1.address like concat('%',t2.title,'%') and t1.address like concat('%',t3.title,'%') and t1.address like '%Рґ. 1%') ) order by 1
com.mysql.jdbc.ServerPreparedStatement[3492] - select t1.address, t1.cid, t4.title, t4.status, t5.val, t6.val, t7.val from contract_parameter_type_2 as t1 left join contract_parameter_type_1 as t5 on t5.cid=t1.cid and t5.pid=1 left join contract_parameter_type_1 as t6 on t6.cid=t1.cid and t6.pid=2 left join contract_parameter_type_1 as t7 on t7.cid=t1.cid and t7.pid=3 left join contract as t4 on t4.id=t1.cid where t1.pid=8 and t1.address='xxxxxxxxxxxxxxxxxxxxxxxxxxxx' and t1.cid=111
com.mysql.jdbc.ServerPreparedStatement[3493] - select t1.val, t1.cid, t1.dt_change, t4.title, t4.status, t5.val, t6.val, t7.val from contract_parameter_type_2_log as t1 left join contract_parameter_type_1 as t5 on t5.cid=t1.cid and t5.pid=1 left join contract_parameter_type_1 as t6 on t6.cid=t1.cid and t6.pid=2 left join contract_parameter_type_1 as t7 on t7.cid=t1.cid and t7.pid=3 left join contract as t4 on t4.id=t1.cid where t1.pid=8 and t1.val='xxxxxxxxxxxxxxxxxxxxxxxxxxxx' and t1.cid=111

_________________
Версия 6.2

А архитектурно прибить проблему никак нельзя?
В Яве нет рельной альтернативы auto_ptr из стандартной либы c++?

Есть обработка при сборке мусора, но обычное закрытие отработает все равно гораздо раньше. Просто иногда желательно закрывать (освобождать) еще раньше.

А сборщик мусора высвобождает ресурсы!?
Но вопрос как раз об высвобождении в нужное время. Нет таких решений в Java?

Есть в 7 яве try-with-resources, но оно тоже не всегда от всего спасёт в нашем случае.

_________________
I'm clever. I've got a computer.

Надо полагать, это аналог шарпового using(){}. Если так, то до auto_ptr ему как до Плутона.
Я слышал от знакомых ява-программеров, что какие-то там Inversion-Of-Control архитектуры позволяют гарантированно управлять ресурсами в Ява. Врут?

причём тут auto_ptr? В java все ссылки всегда и есть auto_ptr. Но за руками выделенными ресурсами как оно интересно должно следить? Нету нигде такого, потому что в принципе невозможно.

_________________
I'm clever. I've got a computer.

Формально, учитывая что GC вызывает деструктор у объекта - да.
Но фактически, из-за того, что в Яве объекты создаются только в куче - НЕТ.

Не понимаю подоплёки

_________________
I'm clever. I've got a computer.

не могу найти этого в нашем коде . Больше похоже на ваши отчеты или скрипты какие-то.. Версия какая?

Действительно, отчет.

_________________
Версия 6.2

В ContractManager.getContractById( cid )
ps не закрывается.


Сервер: вер. 5.2 сборка 1376 от 26.12.2012 17:59:24

Либо не создавать для одного потока, а значит и соединения к БД, каждый раз новый ContractManager, либо вызывать у него recycle(), после того как стал не нужен.

Простите, может быть я что то не понимаю.
У вас в функции public Contract getContractById( int cid ) не закрывается ps (PreparedStatement).
Это не является ошибкой которую нужно исправить?
Нельзя просто добавить в код "ps.close();" или так и должно быть?

Так и должно быть - он кэшируется.

Все понятно, спасибо.

Ув. разработчики!
kernel - класс LimitManager
Насколько я понимаю, довольно много не закрытых PS, в логи ошибок отсюда много летит..

_________________

подчистили