Thanks for the reply! You are right that tcpmon won't support HTTPS.
I have proven the timeout issue is related to the network configuration to that "bad" workstation: I set up a proxy server in a "good" workstation and re-directed all Axis HTTPS requests to the "good" from the "bad", and all queries worked. -----Original Message----- From: Greg Michalopoulos [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 10:12 AM To: [EMAIL PROTECTED] Subject: RE: Question on timeout If you are using https then tcpmon wont be much help because the transmission will be encrypted before it leaves the client/server. If you change your request to http then the server will reject the request. -----Original Message----- From: Yu Feng [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 11:06 AM To: [EMAIL PROTECTED] Subject: RE: Question on timeout Two questions on TCPMon. If I originally wants to connect to https://www.xyz.com/Axis/DownloadService, when I use TcpMon, is this how I should use: set listening port 5050, target host www.xyz.com and target port 443, and change my request to http://localhost:5050/Axis/DownloadService? Second question, I noticed something different when I use Axis1.1 or Axis1.2 to start TcpMon: With above setting (assuming it's correct), with Axis 1.1, I can see connect to www.xyz.com in Request panel; however, with Axis 1.2, it says connecting to www.xyz.com:5050, is this a bug in Axis 1.2? It really should be www.xyz.com:443 if port is shown as well. Yu -----Original Message----- From: Elaine Nance [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 5:37 PM To: [EMAIL PROTECTED] Subject: Re: Question on timeout Maybe the timeout settings? or set up TCPMonitor and see whats going back and forth. Yu Feng wrote: > Thanks for help! > > The computer where this connection problem occurs is our application server, > so I haven't got a chance to replace network card. However, it runs > all other non-Axis applications ok that require Internet connection. > > The exact SocketTimeoutException problem also happened in the > computers that > I said "almost always receives response" -- but very rarely and I > couldn't recreate it if I aim to. So somehow I think that application > server computer > just had worse network configuration that couldn't survive a query > most time. I am wondering if there're some software aspect approach I > can look into? > > I once heard about TCP_NODELAY setup in registry, but apparently > there're no > such setting in any computers here. > > Yu Feng > > -----Original Message----- > From: Elaine Nance [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 14, 2004 2:44 PM > To: [EMAIL PROTECTED] > Subject: Re: Question on timeout > > > I would bet that the Network Interface Card (NIC) is not working > properly, if it is an issue only for one computer. Or that the patch > cord for the computer is bad, for example if someone tripped over it, > and so on. > > Yu Feng wrote: > > >>>Hi, >>> >>>I have been bothered by a time-out issue for quite a few days and >>>wonder if I can get some help from the mailing list. >>> >>>We have a Axis 1.1 client application that connects to a remote Web >>>Service written also in Axis 1.1. The application almost always >>>receives response in all computers excepts one. In that one >>>particular computer, most time it gets SocketTimeoutException as reported widely in Internet: >>> >>>AxisFault >>>faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException >>>faultSubcode: >>>faultString: java.net.SocketTimeoutException: Read timed out >>>faultActor: >>>faultNode: >>>faultDetail: >>>{http://xml.apache.org/axis/}stackTrace: java.net.SocketTimeoutException: >>>Read timed out >>>at java.net.SocketInputStream.socketRead0(Native Method) at >>>java.net.SocketInputStream.read(Unknown Source) ... >>> >>>The only answer I found so far is to increase the timeout value (more than >>>60 seconds) of the binding stub. That didn't work for us. >>> >>>However, the application gets response sometimes (about 5% of all the >>>times we tried) without any change. >>> >>>This convinced me that this might be a computer configuration issue. >>>It has same general configuration as another computer that worked -- >>>Windows 2000, dynamic IP, on the same network. >>> >>>Somebody would have some clue? >>> >>>Thanks! >>>Yu Feng > > > -- > <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | Computers are useless. They can only give you answers. > | -- Pablo Picasso -- > <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > -- <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Computers are useless. They can only give you answers. | -- Pablo Picasso -- <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
