The StackObjectPool allows for unlimited amount of connections in the pool. We experienced with that connection timeouts (most probably because the amount of sockets in the system became huge). Limiting the amount of RedisClients using the GenericObjectPool does fix that.
Also, usage of cloud Redis solutions sometimes have connection limitations, so in that case it is useful to be able to restrict the max amount of connections being allowed. It's anyway good to restrict resource usage as things are finite anyhow (and it's better to be in control of the limit then to let the system limit the resources as the latter might give unexpected exceptions).
The default limit is -1 (unlimited) for backwards compatibility reasons. If you feel that some limit is better, feel free to change.
I've enabled testing on Return (calls validateObject() on the factory), but disabled testing on borrow (as the write method in IO also takes care of that).
The
StackObjectPool
allows for unlimited amount of connections in the pool. We experienced with that connection timeouts (most probably because the amount of sockets in the system became huge). Limiting the amount of RedisClients using theGenericObjectPool
does fix that.Also, usage of cloud Redis solutions sometimes have connection limitations, so in that case it is useful to be able to restrict the max amount of connections being allowed. It's anyway good to restrict resource usage as things are finite anyhow (and it's better to be in control of the limit then to let the system limit the resources as the latter might give unexpected exceptions).
The default limit is -1 (unlimited) for backwards compatibility reasons. If you feel that some limit is better, feel free to change.
I've enabled testing on Return (calls validateObject() on the factory), but disabled testing on borrow (as the write method in IO also takes care of that).