Hello Rahul,
Monday, December 31, 2001, 3:30:56 PM, you wrote:
RA> URLConnection object everytime I send a object. If I don't let the service
RA> method return (of course on certain conditions & not always), I can send as
RA> many objects as I can with jus one connection.
RA> I hope this should work!!!
RA> Any comments??
You should keep in mind that the servlet container may have
a limited pool of threads to server _all_ your requests.
(This is the case with Tomcat, any version).
If you connect to a servlet container via a http server
it may also happend that the http server also has
a limited pool of threads.
For example, if we use Apache + Tomcat this is what
happens:
1) the request is received by Apache
2) one of its threads get busy with the request
(the total pool for Apache may be approx 80-300 threads
that's configurable)
3) this Apache thread communicates with Tomcat
4) one of the Tomcat threads get busy with the request
at the same time the Apache threads patiently
waits untill Tomcat writes all data it
wants and finishes processing the request
5) Tomcat thread calls the service() method
6) When service() returns
6.1) Tomcat thread is free to process
another request
6.2) Apache thread.. well if the client
does not close his end of the connection
and the client has sent a Keep-Alive HTTP header
and the servlet has not sent a Connection: close
header then it waits for 15 seconds for new
HTTP requests on the same connection and
then closes it
I may be a bit wrong on the 6.2 section, and I do not
know how to make use of this connection keeping
stuff.
What I wanted to write about was that while the
service() method does not return both
a Tomcat and Apache thread remain busy,
and as the pools of threads both on Apache
and on Tomcat are limited I can not consider
this a good practice, especially if you
expect any significant load on your server.
You may just run out of the threads this way:
you need one thread per client both on Tomcat
and on Apache.
I think similar things may happen on other
Http server/servlet container combinations.
And if the service method does not return
in reasonable time it is actually an emergency
situation for the servlet container.
It would be best to kill the offending thread
in such a situation (it may have gone into
an eternal loop or anything).. but the Java
api specs discourage such things as killing
threads.. So it is just an emergency, something
the servlet container is not prepared to deal with..
Same true for the http server: it expects that
the module serving the request (in our case
the apache-tomcat module, mod_jk or something alike)
to complete it in reasonable time and if it
does not it's a bad thing.
So the advice:
create a new URLConnection() every time you need
to communicate. Send as much objects as you
can in one interexchange and then drop the connection
(leave the service() method and close your URLConnection)
I would even advise you to do it like this:
applet ------sends _one_ request---> servlet
applet <---receives _one_ response--- servlet
dot. end of communication.
I would advise _against_ doing
applet ------sends request#1----> servlet
applet <---receives response#1--- servlet
applet ------sends request#2---> servlet
applet <---receives response#2--- servlet
cause there might be a caching server in
the middle that will swallow response#1
and wait for the servlet to complete sending
the request untill it sends anything to
the client (applet).
Plese correct me if I'm wrong on this last
point. (I need to do a similar thing
and so I would very much like to be corrected
if I'm wrong)
Best regards, Anton
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
