Re: RES: TCP-FIN problem
I didn't do anything ... the only problem I have is that my app. is not very fast, and that is because it has to wait for tomcat to close the connection, but tomcat closes the connection a lot later (ca 1 minute). My question is now if there is a way to tell tomcat that all data has been written an that the connection can be closend!? Jose Euclides da Silva Junior - DATAPREVRJ wrote: why did you do that? TCP/IP takes care of connection closing for you.Whatis your real problem? -Mensagem original- De: Sebastian Klenk [mailto:[EMAIL PROTECTED] Enviada em: terca-feira, 23 de dezembro de 2003 13:15 Para: [EMAIL PROTECTED] Assunto: TCP-FIN problem Hi everybody, I have an application which calls a webpage (servlet) and parses the response. Now my problem is that the application waits for the closing of the connection (FIN,ACK) wich acures ca 1 minute after the data has been sent. I tried setting content-length header but that doesnt help! does anybody have any advice fore me? thanks in advance Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: TCP-FIN problem
Hi! Sebastian Klenk wrote: I didn't do anything ... the only problem I have is that my app. is not very fast, and that is because it has to wait for tomcat to close the connection, but tomcat closes the connection a lot later (ca 1 minute). My question is now if there is a way to tell tomcat that all data has been written an that the connection can be closend!? Your problem is not tomcat, but the application. Tomcat uses a default timeout of 60 seconds on the socket. But what seems to happen in your case is not tomcat causing that timeout, but _experiencing_ it. Your application is not closing the connection properly and tomcat keeps it open until the timeout occurs. Could you perhaps post more information on that application? Is it written in Java as well? Perhaps you could post some code snipplets? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: TCP-FIN problem
actually i thought that tomcat was supposed to close the connection
after all data has been send - if not this explains a lot!
try {
int c;
while(-1 != (c = Reciever.read())) /* here I'm waiting
until the connection is closed! */
XMLBuffer.append((char)c);
}catch (EOFException e){
}catch (Exception e) {
System.out.println(getServer() : Exception Cought: +
e.getMessage());
return null;
}
Philipp Taprogge wrote:
Hi!
Sebastian Klenk wrote:
I didn't do anything ... the only problem I have is that my app. is
not very fast, and that is because it has to wait for tomcat to close
the connection, but tomcat closes the connection a lot later (ca 1
minute).
My question is now if there is a way to tell tomcat that all data has
been written an that the connection can be closend!?
Your problem is not tomcat, but the application. Tomcat uses a default
timeout of 60 seconds on the socket. But what seems to happen in your
case is not tomcat causing that timeout, but _experiencing_ it.
Your application is not closing the connection properly and tomcat keeps
it open until the timeout occurs. Could you perhaps post more
information on that application? Is it written in Java as well? Perhaps
you could post some code snipplets?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: TCP-FIN problem
Hi! Sebastian Klenk wrote: actually i thought that tomcat was supposed to close the connection after all data has been send - if not this explains a lot! It does, but TCP handshakes are no one-way street. I can only do wild guesses from here, but what I think is happening is this: after tomcat sends the last chunk of data, your application does not release it's hold on the connection, just like as it wants to send more data toward tomcat. After not doing so for a given time (60 seconds) tomcats assumes that the client on the other side has died and reaps the connection. In your code, what is Receiver? Where do you get it from? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: TCP-FIN problem
Maybe with a little bit more detail:
Application Code:
try {
ClientSocket = new Socket(IPAddress, Port);
Sender = new
OutputStreamWriter(ClientSocket.getOutputStream());
Reciever = new
InputStreamReader(ClientSocket.getInputStream());
} catch (UnknownHostException e) {
System.err.println(Unknown host: + IPAddress);
} catch(IOException e){
System.err.println(IOException: + IPAddress + - +
e.getMessage());
}
.
.
.
String Message = new String(Method + + File + HTTP/1.1\r\n);
Sender.write(Message,0,Message.length());
/* HOST */
Message = new String(Host: + IPAddress +: + Port + \r\n);
Sender.write(Message,0,Message.length());
Message = new String(Content-Type: text/xml\r\n);
Sender.write(Message,0,Message.length());
Message = new String(Content-length:
+Data.length()+\r\n\r\n);
Sender.write(Message,0,Message.length());
Sender.write(Data,0,Data.length());
Sender.flush();
.
.
.
try {
int c;
while(-1 != (c = Reciever.read()))
XMLBuffer.append((char)c);
}catch (EOFException e){
}catch (Exception e) {
System.out.println(getServer() : Exception Cought: +
e.getMessage());
return null;
}
Servlet code could look like this
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
try{
Data.getDataSQL(JDBCDriver,JDBCPath,JDBCUser,JDBCPasswd,Edit);
}catch(Exception e){
getLogger().writeToLog(Database Read Statement Error:
+ e.toString() + - + Edit);
}
response.getWriter().print(Data);
response.setContentLength(Data.toString().length());
}
Hope this makes all a little bit clearer!
Philipp Taprogge wrote:
Hi!
Sebastian Klenk wrote:
I didn't do anything ... the only problem I have is that my app. is
not very fast, and that is because it has to wait for tomcat to close
the connection, but tomcat closes the connection a lot later (ca 1
minute).
My question is now if there is a way to tell tomcat that all data has
been written an that the connection can be closend!?
Your problem is not tomcat, but the application. Tomcat uses a default
timeout of 60 seconds on the socket. But what seems to happen in your
case is not tomcat causing that timeout, but _experiencing_ it.
Your application is not closing the connection properly and tomcat keeps
it open until the timeout occurs. Could you perhaps post more
information on that application? Is it written in Java as well? Perhaps
you could post some code snipplets?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: TCP-FIN problem
I already send some more code, and if it helps the (FIN,ACK) comes from tomcat and my app responds with a (ACK) imediatelly, then the connection is closed. but it takes aproximatly 30 seconds till the (FIN,ACK) is send after all data has been send. So it looks like this: ... connection established ... APP: request :TOMCAT APP: data:TOMCAT ... 30 sec. ... APP: FIN,ACK :TOMCAT APP: FIN :TOMCAT ... connection closed Philipp Taprogge wrote: Hi! Sebastian Klenk wrote: actually i thought that tomcat was supposed to close the connection after all data has been send - if not this explains a lot! It does, but TCP handshakes are no one-way street. I can only do wild guesses from here, but what I think is happening is this: after tomcat sends the last chunk of data, your application does not release it's hold on the connection, just like as it wants to send more data toward tomcat. After not doing so for a given time (60 seconds) tomcats assumes that the client on the other side has died and reaps the connection. In your code, what is Receiver? Where do you get it from? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: TCP-FIN problem
Hi, Just yesterday we had a problem with the same symptoms. We corrected it by setting the Content-Length header. Are you sure that you have the correct value for Content-Length? Alex Sebastian == Sebastian Klenk [EMAIL PROTECTED] writes: Sebastian To: Tomcat Users List [EMAIL PROTECTED] Sebastian Subject: Re: RES: TCP-FIN problem Sebastian Date: Tue, 23 Dec 2003 18:36:53 +0100 Sebastian I already send some more code, and if it helps the (FIN,ACK) comes Sebastian from tomcat and my app responds with a (ACK) imediatelly, then the Sebastian connection is closed. but it takes aproximatly 30 seconds till the Sebastian (FIN,ACK) is send after all data has been send. So it looks like Sebastian this: Sebastian ... connection established ... Sebastian APP: request :TOMCAT Sebastian APP: data :TOMCAT Sebastian ... 30 sec. ... Sebastian APP: FIN,ACK :TOMCAT Sebastian APP: FIN :TOMCAT Sebastian ... connection closed Sebastian Philipp Taprogge wrote: Hi! Sebastian Klenk wrote: actually i thought that tomcat was supposed to close the connection after all data has been send - if not this explains a lot! It does, but TCP handshakes are no one-way street. I can only do wild guesses from here, but what I think is happening is this: after tomcat sends the last chunk of data, your application does not release it's hold on the connection, just like as it wants to send more data toward tomcat. After not doing so for a given time (60 seconds) tomcats assumes that the client on the other side has died and reaps the connection. In your code, what is Receiver? Where do you get it from? Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RES: TCP-FIN problem
On Tuesday 23 December 2003 10:53 am, Philipp Taprogge wrote: Hi! Sebastian Klenk wrote: My question is now if there is a way to tell tomcat that all data has been written an that the connection can be closend!? Are you using HTTP for the connection? If so, are you disabling the HTTP keep-alive? Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RES: TCP-FIN problem
Just one little detail with setContentLength(). If you are writing a
string out, make really sure that your content length is correct. If it
is not, the connection will stay open.
A common mistake (at least one I have made) is to think that the
character count in a buffer is the number of bytes in the content.
Depending upon your character set, this may not be true. If you are
using UTF-8, accented characters are almost certainly being written as
two bytes.
-Original Message-
From: Sebastian Klenk [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 23, 2003 10:19 AM
To: Tomcat Users List
Subject: Re: RES: TCP-FIN problem
Maybe with a little bit more detail:
Application Code:
try {
ClientSocket = new Socket(IPAddress, Port);
Sender = new
OutputStreamWriter(ClientSocket.getOutputStream());
Reciever = new
InputStreamReader(ClientSocket.getInputStream());
} catch (UnknownHostException e) {
System.err.println(Unknown host: +
IPAddress);
} catch(IOException e){
System.err.println(IOException: + IPAddress
+ - +
e.getMessage());
}
.
.
.
String Message = new String(Method + + File +
HTTP/1.1\r\n);
Sender.write(Message,0,Message.length());
/* HOST */
Message = new String(Host: + IPAddress +: + Port +
\r\n);
Sender.write(Message,0,Message.length());
Message = new String(Content-Type: text/xml\r\n);
Sender.write(Message,0,Message.length());
Message = new String(Content-length:
+Data.length()+\r\n\r\n);
Sender.write(Message,0,Message.length());
Sender.write(Data,0,Data.length());
Sender.flush();
.
.
.
try {
int c;
while(-1 != (c = Reciever.read()))
XMLBuffer.append((char)c);
}catch (EOFException e){
}catch (Exception e) {
System.out.println(getServer() : Exception Cought: +
e.getMessage());
return null;
}
Servlet code could look like this
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
try{
Data.getDataSQL(JDBCDriver,JDBCPath,JDBCUser,JDBCPasswd,Edit);
}catch(Exception e){
getLogger().writeToLog(Database Read Statement Error:
+ e.toString() + - + Edit);
}
response.getWriter().print(Data);
response.setContentLength(Data.toString().length());
}
Hope this makes all a little bit clearer!
Philipp Taprogge wrote:
Hi!
Sebastian Klenk wrote:
I didn't do anything ... the only problem I have is that my app. is
not very fast, and that is because it has to wait for tomcat to close
the connection, but tomcat closes the connection a lot later (ca 1
minute).
My question is now if there is a way to tell tomcat that all data has
been written an that the connection can be closend!?
Your problem is not tomcat, but the application. Tomcat uses a default
timeout of 60 seconds on the socket. But what seems to happen in your
case is not tomcat causing that timeout, but _experiencing_ it.
Your application is not closing the connection properly and tomcat
keeps
it open until the timeout occurs. Could you perhaps post more
information on that application? Is it written in Java as well?
Perhaps
you could post some code snipplets?
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
