Bo:
Each one of your requests will burn a socket and a thread
(both of which are managed by Tomcat).
So, you'll need to make sure that you don't exceed the limits
on these resources.
However, keeping an open socket connection for 'long' periods
of time may not be the best way of meeting your goals.
RMI may be a better choice, however, you may run into firewall
issues.
Assuming that you really want to stick to the HTTP connection,
your initial request could start a new 'thread' on the server (that
you manage with code you write). The server would need
to return an identifier that the applet passes along with subsequent
requests so that your server can find the corresponding object/thread,
and retrieve any data that is 'available'. This way, you don't burn
more sockets than you really need. The server could 'cancel'
any objects/threads that haven't been asked for (by an applet) after
some time period. This would help limit the number of threads in your
server.
The cost of this solution is in making/breaking multiple TCP connections
for each request, but the advantage is that you gain control over what
resources the server is using.
Good Luck
Tom Drake
----- Original Message -----
From: "Bo Xu" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 23, 2002 10:41 AM
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
|
|
|
| --
| To unsubscribe: <mailto:[EMAIL PROTECTED]>
| For additional commands: <mailto:[EMAIL PROTECTED]>
| Troubles with the list: <mailto:[EMAIL PROTECTED]>
|
|
|
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
