Ошибка тайм-аута соединения HikariCP после определенного количества запросов

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

По сути, я получаю трассировку HikariCP, и я не знаю, что ее вызывает.

java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30000ms.
at com.zaxxer.hikari.pool.HikariPool.createTimeoutException(HikariPool.java:548)
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:186)
at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:145)
at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:83)
at de.arraying.Arraybot.managers.ManagerSync.addCustomCommand(ManagerSync.java:192)
at de.arraying.Arraybot.commands.CommandsCommand.onCommand(CommandsCommand.java:100)
at de.arraying.Arraybot.commands.Command.execute(Command.java:72)
at de.arraying.Arraybot.listeners.ListenerChat.onGuildMessageReceived(ListenerChat.java:68)
at net.dv8tion.jda.core.hooks.ListenerAdapter.onEvent(ListenerAdapter.java:299)
at net.dv8tion.jda.core.hooks.InterfacedEventManager.handle(InterfacedEventManager.java:64)
at net.dv8tion.jda.core.handle.MessageCreateHandler.handleDefaultMessage(MessageCreateHandler.java:97)
at net.dv8tion.jda.core.handle.MessageCreateHandler.handleInternally(MessageCreateHandler.java:47)
at net.dv8tion.jda.core.handle.SocketHandler.handle(SocketHandler.java:38)
at net.dv8tion.jda.core.requests.WebSocketClient.handleEvent(WebSocketClient.java:688)
at net.dv8tion.jda.core.requests.WebSocketClient.onTextMessage(WebSocketClient.java:437)
at com.neovisionaries.ws.client.ListenerManager.callOnTextMessage(ListenerManager.java:352)
at com.neovisionaries.ws.client.ReadingThread.callOnTextMessage(ReadingThread.java:262)
at com.neovisionaries.ws.client.ReadingThread.callOnTextMessage(ReadingThread.java:240)
at com.neovisionaries.ws.client.ReadingThread.handleTextFrame(ReadingThread.java:965)
at com.neovisionaries.ws.client.ReadingThread.handleFrame(ReadingThread.java:748)
at com.neovisionaries.ws.client.ReadingThread.main(ReadingThread.java:110)
at com.neovisionaries.ws.client.ReadingThread.run(ReadingThread.java:66)

Я пытался изменить maximum pool size, minimum idle, а также включил leak detection (на 2 с). Ничто из этого не помогло, за исключением того, что я получаю обнаружение утечки каждый раз, когда выполняю запрос, так что, возможно, это связано с этим.

Это моя текущая конфигурация:

    HikariConfig hikariConfig = new HikariConfig();
    hikariConfig.setJdbcUrl("jdbc:mysql://"+url+":3306/"+database+"?useSSL=false");
    hikariConfig.setUsername(username);
    hikariConfig.setPassword(password);
    hikariConfig.setMaximumPoolSize(10);
    hikariConfig.setMinimumIdle(3);
    hikariConfig.setLeakDetectionThreshold(2000);
    dataSource = new HikariDataSource(hikariConfig);

Мои методы запроса структурированы следующим образом:

        // inside a try/catch, after some checks that aren't related.
        PreparedStatement preparedStatement =
                dataSource.getConnection().prepareStatement(query);
        preparedStatement.setString(2, id);
        preparedStatement.setString(3, name);
        preparedStatement.setObject(1, value);
        preparedStatement.executeUpdate();
        preparedStatement.close();

Я должен закрыть соединение после этого или что-то в этом роде? Единственное, что я могу себе представить, что может вызвать ошибку, - это утечки памяти, и я не думаю, что у меня они есть. Мое использование ЦП тоже в порядке, как и мое интернет-соединение. Все запросы работают отлично, за исключением того факта, что эта ошибка просто начинает выдаваться через несколько раз.


person Arraying    schedule 02.02.2017    source источник
comment
Поскольку он говорит request timed out after 30000ms., я думаю, что это проблема, связанная с сетью, или у вашего сервера БД больше нет подключений?   -  person Redlab    schedule 02.02.2017
comment
@Redlab, как я могу подтвердить, что у него больше нет соединений?   -  person Arraying    schedule 02.02.2017


Ответы (1)


«Я получаю обнаружение утечки каждый раз, когда выполняю запрос».

Конечно же. В вашем примере вы получаете Connection из DataSource, выполняете PreparedStatement, закрываете PreparedStatement, затем не закрываете Connection, поэтому он не возвращается в пул и приводит к утечке.

Закройте свои связи люди! Только вы можете предотвратить форс... эээ, утечку соединения.

person Kayaman    schedule 02.02.2017
comment
Хорошо, спасибо, что сообщили мне, я предположил, что CP обрабатывает открытие и закрытие соединений для меня. Я думаю, именно поэтому вы не должны предполагать... Сейчас я обновлю свой код и посмотрю, изменится ли что-нибудь... - person Arraying; 02.02.2017
comment
Когда вы вызываете close(), соединение на самом деле не закрывается, оно возвращается в пул (поскольку close() переопределяется некоторым классом HikariConnection, который реализует некоторую логику пула). - person Kayaman; 02.02.2017
comment
Я выполнил более 20 запросов, ни один из них не дал мне ошибки или предупреждения об утечке памяти, надеюсь, закрытие соединения исправило это. - person Arraying; 02.02.2017
comment
О, я могу это гарантировать. Хотя это не значит, что нет других проблем. Моя гарантия распространяется только на незакрытые соединения. - person Kayaman; 02.02.2017