----- Original Message -----
From: "Bo Xu" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 23, 2002 1:41 PM
Subject: Re: About persistent
> ----- Original Message -----
> From: "Vjeran Marcinko" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Wednesday, January 23, 2002 12:45 PM
> Subject: About persistent
>
>
> Hi again.
> One more question, and yes, I know this
> isn't standard usage that servlets are made for, but
> situation is like this -
>
> I have to create servlet that will never exit its doPost() method,
> and that way be able to keep response's output stream constantly
> open, and send asinchronous messages to applet which has sent
> that POST request.
> Tell me, since there will be bunch of applets keeping this persistent
> connections, will it crash somehow Tomcat ?
> I don't know Tomcat's internal structure, so I'm wondering is there
> a case when all servlet threads from thread pool (I assume it exists in
> Tomcat) could be used (since never exiting), thus freezing whole web
> service ?
> And is there some timeout implemented for response, when they last too
long
> ?
>
> Thanx,
> Vjeran
> [...]
>
>
>
> * about "timeout":
> the following is from server.xml in TOMCAT4.0:
> <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
> <Connector
className="org.apache.catalina.connector.http.HttpConnector"
> port="8080" minProcessors="5" maxProcessors="75"
> enableLookups="true" redirectPort="8443"
> acceptCount="10" debug="0" connectionTimeout="60000"/>
> <!-- Note : To disable connection timeouts, set connectionTimeout
value
> to -1 -->
>
> I think "60000"(60s) will be set into
> org.apache.catalina.connector.http.HttpConnector, and in:
> org.apache.catalina.connector.http.HttpConnector,java:
> ...
> private int connectionTimeout = Constants.DEFAULT_CONNECTION_TIMEOUT;
> ...
> public void setConnectionTimeout(int connectionTimeout) {
> this.connectionTimeout = connectionTimeout;
> }
> ...
> public void run() {
> ...
> socket = serverSocket.accept();
> ...
> if (connectionTimeout > 0)
> socket.setSoTimeout(connectionTimeout);
> socket.setTcpNoDelay(tcpNoDelay);
> } catch (AccessControlException ace) {
> ...
>
>
> so I guess there will be a "TimeOut" Exception when container is in a
> "reading-status" but can not get any(more-than-1) byte within 60s.
> so normally your Applet need to send at least 1 byte during 60s.
>
> but if your Servlet is "writing" bytes to client, I guess you will not
> get "TimeOut". (Is my guessing right? Thanks :-) ) the following
> is from doc of J2SE1.3:
>
> java.net.Socket.setSoTimeout
> public void setSoTimeout(int timeout)
> throws SocketExceptionEnable/disable SO_TIMEOUT with the specified
timeout,
> in milliseconds. With this option set to a non-zero timeout, a read() call
> on the InputStream associated with this Socket will block for only this
> amount of time. If the timeout expires, a java.io.InterruptedIOException
is
> raised, though the Socket is still valid. The option must be enabled prior
> to entering the blocking operation to have effect. The timeout must be >
0.
> A timeout of zero is interpreted as an infinite timeout.
>
>
>
> * about Thread:
> I guess it is better to keep a short-time HTTP request/response, but
> because your application need a long/forever one, so I think you can
> try, and:
> - another way is keep the client-status in server-side(for ex., how many
> bytes have already been read/written), and in client-side(Applet),
> connect to Servlet periodicly(to release/re-made the http-connection)
>
>
> Bo
> Jan232002
>[...]
I forgot one :-)
* about Thread:
- ...
- if the client ends the connection, your "doPost" code needs to find it
(by a Exception? or other), and ends this "doPost" method, so this
Thread will be released.
Bo
Jan232002
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
