Hi Paolo, Something to remember is that tcp/ip is stateless. Therefore any higher level protocol is susceptible to this nature. Http does not provide provision for state; therefore http-client can do nothing other than check flags for previously known states in order to determine whether or not a connection is open.
This means that at any given point in time; isOpen could be inconsistent with the network connection's actual state. If you check the socket implementation from the JDK you'll see too that its isConnected api simply returns internal state as well which could be inconsistent with the actual state. Raymond On Dec 10, 2007 4:29 AM, <[EMAIL PROTECTED]> wrote: > Hi All, > > Im having difficulty finding a good way to determine whether or not my > connections are actually open before I send my message to the server. Im > using the MTHCM, I have one thread responsible for sending messages and > another thread responsible for checking the connection. To check the > connection i use the getConnection method from MTHCM, then call isOpen(). > This method returns true even when Ive disabled my network interface. I > have setStaleCheckingEnabled = true. > > Is there an easy way to check if my sockets are still open? I assume that > Im using the library incorrectly but I can not find any other reference to a > similar issue. > > Any help would be much appreciated. > > Regards, > > Paolo Mentonelli > > Based on the present E-Mail exchange, and/or on the agreement reached > with you, respectively, UBS is entitled to contact you via insecure > E-Mail: > (a) E-Mails contain substantial risks such as lack of confidentiality, > manipulation of content and sender, misdirection, viruses etc. UBS > does not accept any liability for damages arising from use of > E-mail. Accordingly, UBS recommends to abstain from sending any > sensitive information via E-Mail, from forwarding the text received > when submitting reply E-Mails and recommends to manually capture the > E-Mail address in every instance. If you should wish to verify the > content of this message, please request a hard-copy version. > (b) In principle, UBS does not accept any (purchase) orders, > cancellation of orders or authorizations etc. via E-mail. If UBS > receives such E-Mails, UBS is not obliged to expressly decline them. > If you have received this E-Mail by mistake or do not wish to be > contacted by E-Mail in the future, you are kindly asked to inform UBS > accordingly. Any E-Mail received by mistake (including all its annexes) > needs to be destroyed and the content may not be forwarded nor disclosed > to any further persons. > c) This message is provided for informational purposes and should not be > construed as a solicitation or offer to buy or sell any securities or > related financial instruments. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- --------------------------------------------------------- Raymond Kroeker
