feat: enable session leaks prevention by cleaning up long-running tra…

[arpan14]

Adding a couple of option in SessionPoolOptions for auto-detecting long running transactions, logging the stack-trace and removing such transactions from consuming more resources. There can be scenarios where transactions are unexpectedly taking more time and hence can consume the session for longer durations. With this change, customers get two new options which can be set while providing SessionPoolOptions

1. setWarnIfInactiveTransactions() - Calling this method will generate warning logs and help in identifying faulty code which is leading to incorrect consumption of sessions.
2. setWarnAndCloseIfInactiveTransactions() - Calling this method will close the faulty transactions that are consuming the resources. We will also be generating the warning logs which can be later referred to know the transactions that were closed through this option.

Reference Feature PR - #2419

[asthamohta]

I think for java we won't have this log right so we can remove the line?

[olavloite]

Are we logging in the Java client? Based on the comment above, I would expect 'No'.

If we are logging: I'm pretty sure that we are not pushing those logs to any 'destination based on how the log exporter is configured'.

[arpan14]

Some of the other client libraries such as Node/Python, emit an additional log every-time the application uses > 95% of the sessions. In Java, we use the condition as a pre-condition for the algo but don't emit any log for this condition. We only emit one of the below logs,
a) WARN LOG - when there is an actual long-running transaction. This includes bunch of other pre-conditions conditions (lastUsedTime, type of Transaction, etc.)
OR b) WARN LOG - We have automatically cleaned a long running transaction

Now what I mean as pushing log to the exporter is - the logs will be stored in a destination as per what is configured for the application. For ex - Some apps may configure cloud logging while others could configure logs to be stored on separate files on the app server.

The note about the exporter is not too relevant for Java where there is a default logging behaviour and I think it was more relevant for other languages like Node where a default logging capability was absent. We added a custom logging capability in Node (as part of sessions leaks) where the default logging was console logs or you could define some other exporter.

LMK if this documentation can be better framed or excluded in context of Java client.

[olavloite]

We're using java.util.logging for this, right? Then I would just explicitly call out that. So something like 'The warning is logged using java.util.logging.'. I think that most people know what they need to do to configure that, and can otherwise search for it.

[Flyboy-60]

---

[Flyboy-60]