commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Nørgaard <>
Subject Re: [net] TelnetClient on Solaris - timeout problem
Date Fri, 31 Jan 2003 14:39:26 GMT

Thanks for the reply.

That sounds like a reasonable approach for the release. I will try 
creating a special factory sometime next week.

>In message <p05210200ba5e86b720c2@[]>, 
>=?iso-8859-1?Q?J=F8rgen?= =?
>iso-8859-1?Q?_?= =?iso-8859-1?Q?N=F8rgaard?= writes:
>>On Solaris however all connections using commons-net timeout after
>>around 4 mins.
>>The only way I see to do something on Solaris is to use jdk1.4.x
>>which has a more elaborate api for Sockets. The program "sock"
>>illustrates this.
>Right, so what you're saying is that you want to shorten how long it
>takes for a connect fail if a connection hasn't been established.
>Yes, prior to the J2SE 1.4, there was no way to do this.  With
>J2SE 1.4 you can either use the connect(SocketAddress, int timeout)
>method the way you did in or use the java.nio package to
>do a non-blocking connect and use select to implement a timeout, the
>way you would in POSIX/C.  For your purposes, you have a couple of
>options.  However, the easiest thing to do, which will require you
>to make absolutely no changes to the commons-net source code, is
>to subclass DefaultSocketFactory and reimplement the createSocket()
>methods so that they create an unconnected socket and then use
>Socket.connect(SocketAddress, int timeout) to establish a connection.  You
>can add a timeout to be used by the SocketFactory (setter and getter
>and constructor argument) when creating a connected socket.  Then just
>create an instance of the SocketFactory and use
>SocketClient.setSocketFactory(SocketFactory) to set the factory used
>by your TelnetClient instance.
>For our purposes, we have to put out a first formal release before making
>changes of this sort.  For one thing, we have to agree on a backward
>compatibility strategy.  My suggestion is that the first release be made,
>which given the current code should be compatible with JDK 1.1 through 1.3.
>After this, I suggest we abandon compatibility with prior versions of Java
>and leverage J2SE 1.4 features as appropriate.  For example, there is no
>reason for the telnet stuff to use threads now that we have non-blocking I/O.
>Changing from a thread-based implementation to a select-based loop will
>eliminate problems on some platforms, use less resources, be more efficient,
>etc.  Also, J2SE 1.4 finally added SocketFactory and ServerSocketFactory
>classes in, possibly eliminating the need for
>  The classes are almost
>identical to ours and I wonder if the creators of read an article
>I wrote years ago enumerating many of the flaws in or they just
>finally realized what should have been obvious to anyone.  Anyway,
>ours has the advantage of being an interface, but the disadvantage of
>not being refactored into two interfaces.  I'm hijacking the
>thread, so I'll delay further discussion until after our first release.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

/jørgen nørgaard                               ... For privacy ...
e-mail: | Phone: +45 2627 3769                            ... PGP! ...
                                         |\      _,,,---,,_
                                         /,`.-'`'    -.  ;-;;,_ 
                                         |,4-  ) )-,_. ,\ (  `'-'
                                        '---''(_/--'  `-'\_)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message