Wang, now I see, and I agree with your concern. When you told me about http1.1 keep alive feature I thought setTimeout was related to this only (in MessageContext JavaDoc, about setTimeout method I can read no more than: "set timeout in our message context"). And using with TCPmon (as you suggested me) I was able to establish that I was not using keep alive. For this reason I thought the two things were not related (even because, actually, setting lower timeout had no effect at all). Then I saw in the code that there was no socket pooling, just missing socket closing...
After your reply, I switched back to the situation I was before trying to "patch" Axis, and the timeout setting had the desired effect. Now I'm trying to reproduce my problem, but _I can't_. I have to say that my problem is unreproduceable, even by me. I'm sorry. But the same not-working code I was using some days ago, now seems to work fine (socket are closed after a timeout period). The system was not restarted. Just a few services were restarted... I can't tell... I can't even try to guess... Maybe apache... Now I can see a zombie httpd process (ps -axj | grep -i " Z " shows an "httpd <defunct>"), but I can't argue nothing but the fact that I'd better to restart services more often than three times a year... My only concern about letting the sockets close "automatically" (without socket pooling), is that if something goes wrong (as happened to me, somehow...) it is possible that sockets remain "unbinded" and unusable. About Tasos Kotsikonas's reply: > Why not close the socket right in the invoke() method? If closing manually the socket was good, your hint would be good too. But I changed my mind about this. Anyway, I appreciated very much the help you all gave me. Thank you. Bye, Matteo. > -----Messaggio originale----- > Da: Wang, Pengyu [IT] [mailto:[EMAIL PROTECTED] > Inviato: mercoledì 5 novembre 2003 16.24 > A: [EMAIL PROTECTED] > Oggetto: RE: Too many CLOSE_WAIT socket connections > > If you set SoTimeout, it will close for you if you no longer > using that socket (because of no activity). In messageContext > you can call setTimeout to achieve this. > > But if it works for you the way you describe, then it is good. > > My only concern to your solution is : if in the future Axis > Client starts to pooling sockets, or in RPC the socket always > keep open, then you might be forced to touch your code again. > While setTimeout is an interface call in MessageContext and > it always should be valid (in terms of open socket tunnel, > underline implementation can choose to send heartbeat to > maintain the connection), then no matter what Axis Client > implementation version you don't need to touch your code.
