Putting Jsch into connection pool in details

Question

I put Jsch into commons-pool (with spring pool support) with initial success

http://docs.spring.io/spring/docs/3.2.4.RELEASE/spring-framework-reference/htmlsingle/#aop-ts-pool

However:

1. Should we pool the channels within the Session instead of pooling the sessions? Each Jsch session creates one thread. Pooling Jsch sessions will create x threads. Pooling channels, there will really be only one Jsch thread.

2. (commons-pool) what happens if the Jsch session went stale? How to regenerate the session in the context of the commons-pool or using spring pool support? How to detect whether it goes stale?

Thanks

Answer 1

Figured out my own question. I will share my project in the next day or two.

1. Pooling channels are much more effective. There is really no need to create multiple sessions (if the session connects to the same sftp endpoint).

2. I implemented a JSch connection pool (pooling channels) with spring pool and commons-pool. I will post to the github in the next day or two. The most important question is, what if the connection went stale.

I found out that based on my implementation of 1 Session - multiple channels, and if the connection went stale, the pooled objects (in this case, the channel) will be stale. The pooled object should be invalidated and deleted from the pool. When the connection comes back up, and when new application thread "borrows" from the pool, new pool objects will be created.

To validate my observation, my not-so-automated test:

a) Create a set (say 10) of app threads checking out channel resource from the pool. b) Have the thread to sleep 20 seconds c) Create another set of app threads checking out channel resources from the pool.

At a), set breakpoint when i==7, break the connection by "iptable drop (linux) or pfctl -e; pfctl -f /etc/pf.conf (mac, google how to do!)". This first set of app threads will get exception because the channel is broken.

At b), restart the connection

At c), the 2nd set of app threads will be successfully completing the operation because the broken connection has been restored.