JSch: How to keep the session alive and up

Question

I\'m writing Java GUI program for static route management using SSH. My code is as follows:

import com.jcraft.jsch.*;
import java.io.*;

public class Konsep          


        

Answer 1

After trying Session.sendKeepAliveMsg() without success, I came to the following solution which seems to be rather stable:

private Session getSession() throws Exception {
    try {
        if (!session.isConnected()) {
            logger.info("Session successfully tested, use it again.");
            session.connect();
        }
    } catch (Throwable t) {
        logger.info("Session terminated. Create a new one.");
        session = jsch.getSession(user, host, port);
        session.setConfig(config);
        session.connect();
    }
    return session;
}

Update: Some days later it failed.

I tried to test it by killing the open session on the server. All prior versions I tested this way showed the exact same behavior, regardless whether the problem popped up after waiting some days or killing the server process, so I thought this test - and its outcome for the above solution - to be meaningful. Unfortunately, it isn't.

I'm going to try some other ways to fix it and keep you up to date.

Update 2: Final solution, guaranteed inelegant and working:

private Session getSession() throws Exception {
    try {
        ChannelExec testChannel = (ChannelExec) session.openChannel("exec");
        testChannel.setCommand("true");
        testChannel.connect();
        if(logger.isDebugEnabled()) {
            logger.debug("Session successfully tested, use it again.");
        }
        testChannel.exit();
    } catch (Throwable t) {
        logger.info("Session terminated. Create a new one.");
        session = jsch.getSession(user, host, port);
        session.setConfig(config);
        session.connect();
    }
    return session;
}

This version runs several weeks in a productive environment. Once a day I have the info message logged.

The costs of opening a channel and performing some do-nothing-command are somewhat annoying, but I found no other way to be definitely sure about the state of the session.