Обсуждение: Idle_session_timeout

Поиск
Список
Период
Сортировка

Idle_session_timeout

От
Rajesh Kumar
Дата:
Hi all,

I was facing issue with idle connections not closed.

So, I thought of automating it and set the parameter idle_session_timeout to 5min. But I got a message from application team that they are getting jdbc error continuously and they are saying connection is getting terminated. So I had to turn it off now.


How to use this parameter correctly?

Re: Idle_session_timeout

От
Scott Ribe
Дата:
> On Oct 4, 2023, at 9:38 AM, Rajesh Kumar <rajeshkumar.dba09@gmail.com> wrote:
>
> So, I thought of automating it and set the parameter idle_session_timeout to 5min. But I got a message from
applicationteam that they are getting jdbc error continuously and they are saying connection is getting terminated. So
Ihad to turn it off now. 

You're not doing anything incorrectly. You just have a mismatch between expectations on the database vs application
side.

Either:

the application is allowed to keep connections open permanently, and the database has to be configured to support
enoughconnections 

-OR-

the database has a more limited number of connections, and the application manages connecting and disconnecting





Re: Idle_session_timeout

От
Goran Pulevic
Дата:
You need to talk to your application team and find out about their connection related timeouts. Things like max-idle-time, server-lifetime, etc. (They almost certainly use a db library which implements some kind of client side connection pool).
In short: their timeouts should be lower than the server's idle_session_timeout.
Something like: max-idle-time <  server-lifetime <   idle_session_timeout

On Wed, 4 Oct 2023 at 17:41, Rajesh Kumar <rajeshkumar.dba09@gmail.com> wrote:
Hi all,

I was facing issue with idle connections not closed.

So, I thought of automating it and set the parameter idle_session_timeout to 5min. But I got a message from application team that they are getting jdbc error continuously and they are saying connection is getting terminated. So I had to turn it off now.


How to use this parameter correctly?

Re: Idle_session_timeout

От
Rajesh Kumar
Дата:
Looks like they are fine with keeping one connection open per client_addr and close remaining idle >5mns. Seems like they already have a query deployed in golang and it doesn't seem to be work well for some reason 

What's the best choice to automate this. The platform is kubernetes and cron is not possible for now. Any idea what's the best now?

On Wed, 4 Oct, 2023, 9:53 PM Goran Pulevic, <goranmp@gmail.com> wrote:
You need to talk to your application team and find out about their connection related timeouts. Things like max-idle-time, server-lifetime, etc. (They almost certainly use a db library which implements some kind of client side connection pool).
In short: their timeouts should be lower than the server's idle_session_timeout.
Something like: max-idle-time <  server-lifetime <   idle_session_timeout

On Wed, 4 Oct 2023 at 17:41, Rajesh Kumar <rajeshkumar.dba09@gmail.com> wrote:
Hi all,

I was facing issue with idle connections not closed.

So, I thought of automating it and set the parameter idle_session_timeout to 5min. But I got a message from application team that they are getting jdbc error continuously and they are saying connection is getting terminated. So I had to turn it off now.


How to use this parameter correctly?

Re: Idle_session_timeout

От
Laurenz Albe
Дата:
On Wed, 2023-10-04 at 21:08 +0530, Rajesh Kumar wrote:
> I was facing issue with idle connections not closed.
>
> So, I thought of automating it and set the parameter idle_session_timeout to 5min.
> But I got a message from application team that they are getting jdbc error
> continuously and they are saying connection is getting terminated.
> So I had to turn it off now.

Yes, if the connection is forcibly closed by the server, the client won't be happy.

If you say "idle connections not closed", that is the fault of the application.
The application has to explicitly close all connections it does not need any more.

Yours,
Laurenz Albe