Providing JedisPool to be created with abandon config

[venukbh]

There are a lot of discussions and forums indicating connection issues, maxing out over period of time, connections leakage and not returning to pool.

This abandon config will give the client an option to abandon connections which are not returned back in a specified time - making the connection pool steady and available for app all the time

[venukbh]

@gkorland : Can you approve this PR. This PR has helped us fix an issue by cleaning the connections which are being left active due to various reasons at app level for life time

[venukbh]

Hi @argvk Can you approve this PR. I do not see any use case to write a junit as I am just providing an additonal constructor. This change helps us to fix lot of consumers whose connections are getting stale over time and systems going bad.

[argvk]

hey @venukbh, I am not a maintainer, and haven't worked on this repo for a long time. You should reach out to the maintainers.

[venukbh]

@gkorland Can you take a look and approve. Even Redis enterprise team found it useful. Let me know of any thing to clarify

[venukbh]

@sazzad16 @karltinawi @ullenius @Talon876 : Can you please take a look at this and merge... This is much needed when the connections are not being released by the system

[sabir012]

Hi all,
Is there any action to merge this change to master? I also found the same issue with active connections.

[sazzad16]

@sabir012 @venukbh It is hard to accept a PR without tests even if ill-formatted codes are ignored.

[venukbh]

@sazzad16 I do understand about the test cases importance. But I am just providing constructors, and I do not see any existing test cases for constructors as well.

[venukbh]

@sazzad16 Can you please merge this pr? The change introduced helps a lot of clients using redis to get rid of the connection pool issues.

[karltinawi]

hi @venukbh - sorry for the lateness in replying, I am not a maintainer either. Hope you get this merged soon..!

[venukbh]

@sazzad16 @gkorland can you approve this?

[gkorland]

@venukbh I think that instead of overloading another Constructor (and perhaps many more) we should just expose setAbandonedConfig in Pool.java