Запуск atomikos
в одной из наших сред с минимальным размером пула подключений 20 и максимальным размером пула подключений 30, время подключения установлено на 10 секунд. Приложение интенсивно использует дб, и каждое действие дб в среднем занимает 2 секунды.
У нас было несколько экземпляров с числом входящих потоков от 30+ и со всеми потребляющими соединениями, когда это происходит, количество заблокированных потоков возрастает до 500+ на сервере tomcat и заставляет наш apache http-сервер cra sh из-за ограничения ресурсов коннектора ajp.
Синхронизируется AtomikosNonXADataSourceBean.getConnection()
, что не позволяет задействовать таймаут для borrowConnection()
, когда мы смотрим на реализации из HikiariDataSource
, метод getConnection()
не блокирует, а вызывает * Метод 1010 *, который использует комбинацию SuspsendResumeLock
(внутри семафора) и Синхронной очереди с тайм-аутом опроса на getConnection()
, чтобы обеспечить высокую пропускную способность и быстро потерпит неудачу.
Мы не можем перейти на Hikari из-за других недостатков в приложении и хотели бы, чтобы Atomikos обеспечивал пропускную способность, внося небольшие изменения? Кто-нибудь сталкивался с такими проблемами с потенциальным разрешением?