#26 The input read is going to blocked state forever

[Juris Zubkans]

The input read has blocked state forever and connections are not cleaned by housekeeping, new connections can't be established

the code in
TelnetIO.initTelnetCommunication
has this
} finally {
374 //this is important, dont ask me why :)
375 try {
376 m_ConnectionData.getSocket().setSoTimeout(0);
377 } catch (Exception ex) {
378 log.error("initTelnetCommunication()",ex);
379 }
380 }
the socket read timeout is set forever and mens that all examples of shell use are wrong and lead to dead lock code. The clean up HK in ConnectionManager will try to check all inactive connections and if in DummyShell
3 public void connectionIdle(ConnectionEvent ce) {
254 try {
255 m_IO.write("CONNECTION_IDLE");
256 m_IO.flush();
257 } catch (IOException e) {
258 log.error("connectionIdle()", e);
259 }
260
261 }//connectionIdle
will try to write something to already by read method blocked input stream, and will stop here for ever.
More over the all other connections can't be established to the running daemon.

How to reproduce:
set warning property to 1min
std.time_to_warning=60000
connect and do nothing, wait some time and try to connect with other terminal: result new connection can't be established

IMO the proper solution should be to have new property
std.read_timeout = 60000
and instead of 0 set
m_ConnectionData.getSocket().setSoTimeout(read_timeout);

This will prevent housekeeping deadlocks and end application Shells can catch SocketTimeoutException and act accordingly
something like

Editfield command;
try {
command = new Editfield(m_IO, "command", 9999);
command.run();
} catch (SocketTimeoutException socex) {
m_IO.write(BasicTerminalIO.CRLF + "Input timeout, reading next...");
continue;
}