Re: (New subscriber) "Busy Page" - Aarrrrggggghhhhh.....

Eric Noriega <[email protected]> Thu, 28 Oct 2004 16:25:59 -0400
Newsgroups gmane.comp.java.sun.servlet
Organization The George Washington University, Department of Computer Science
Message-ID <[email protected]>
    I thought I would add in the fact that JDK 1.5 adds in
java.util.concurrent.Executors and thread pools, which can be much more
efficient than creating many new Threads.

    I don't think that for a simple case, there is a problem with
creating a busy page, and processing the request in the same VM.  If you
find that you have problems with memory or thread exhaustion, then you
can refactor to a larger solution.

Nic Ferrier wrote:

>Zerbe John W <[email protected]> writes:
>
>
>
>>My own background is that of a mainframe assembly language programmer on a
>>team of people who supported a "home grown" TP monitor that is much like
>>and predates IBM's CICS product. By the way, this TP monitor is still in use
>>today and can still perform well on a machine that is running at 99% cpu busy.
>>I guess that makes me a bit sensitive to how the applications use/abuse
>>the supporting infrastructure. After having spent years preaching to
>>application programmers how queueing theory works and getting transaction
>>response times measured in the milliseconds, I still find it difficult to
>>imagine building an application where 10+ second response times are
>>"acceptable".
>>
>>
>
>10+ second response times are not acceptable. That is the whole point
>of this thread!
>
>As you rightly intimate, asychronous coding is the way round such
>delays and that is what everyone in this thread has been talking
>about.
>
>Briefly the Java based suggestions to solve the problem have been:
>
>- dispatch a new Thread from the servlet request handler method to do
>  the work and respond to the user with a "check status page"
>
>- variation on the above: respond to the user with a "check status
>  page" but then continue using the servlet container's Thread  to do
>  the actual work
>
>- use JMS to queue the work to some other place
>
>- call a db stored proc to do the same (though this presumes your DB
>  supports queuing... Oracle maybe?)
>
>--
>Nic Ferrier
>http://www.tapsellferrier.co.uk
>
>___________________________________________________________________________
>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
>
>

___________________________________________________________________________
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