tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Long running requests and timeouts?
Date Mon, 17 Jan 2005 16:10:19 GMT
I can't answer your specific question, but the scenario you describe 
raises a red flag with me in general...

When you potentially have such long-running requests, it's usual a Bad 
Idea(tm) to just allow them to run like this as part of a request.  I 
think it's fair to say that most people would say you should be taking 
some sort of queueing or multithread approach, coupled with polling.

I don't know your usage pattern, but especially if there could be a 
number of such requests coming in at once, you are tieing up server 
resources this way.  You also start running into situations like you 
mention with timeouts (I'm actually surprised the browser itself didn't 
time out after a few minutes).  It also doesn't give a very good 
appearance to the user... it seems like the system has just frozen, 
which it actually hasn't.

If it's feasible, I think you may save yourself some trouble by 
rearchitecting this rather than trying to solve this problem.  You can 
do something as simple as this...

(1) Have a class with two static HashMaps.  One HashMap we'll call 
THREADS and it will store a reference to an object (more on this in a 
second), keyed by userID... In the other that we'll call STATUS you will 
store a Boolean, also keyed by userID.
(2) When one of these long-running requests comes in, spawn a thread to 
handle the XML generation, and put a reference to the thread in that 
THREADS HashMap for the userID your servicing (might want to use 
sessionID instead, it's up to you)... In the STATUS HashMap, store a 
false Boolean (false means the request hasn't completed yet).
(3) Return a "Plase Wait" page to the user.  Use a simple JavaScript 
timeout to call a status checking function every few seconds that checks 
the value of the Boolean.  If false, just return that Please Wait page 
(4) When the thread completes, it should set that Boolean to true for 
that userID.
(5) When the status checking function finds True, it should (a) get the 
reference to the thread from the THREADS HashMap, (b) get the XML from 
the thread (just store it in a class-level variable and expose it with a 
getter), (b) set some value in the thread object that indicates the 
thread should die, (c) return the XML to the browser.

Does that all make sense?  I don't know if your in a position to 
rearchitect what your doing, but if you are, I very much suggest doing 
so.  Hope this helps!

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

Andrzej Jan Taramina wrote:
> I have a situation where some requests that get sent to Tomcat are very long 
> running (basically batch operations).  I've been testing with a request that 
> takes just over 7 minutes to process and returns and XML document as a 
> response.
> The problem I'm having is that the response gets truncated.  It's always 
> truncated at a consistent spot (3207 characters for some reason, that's what 
> Firefox reports).
> Shorter running requests don't truncate anything, regardless of how long the 
> response might be.
> I'm running Tomcat 5.0.28 and my Connector in the Tomcat server.xml file 
> looks like:
> <Connector port="80"
> 	maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
> 	enableLookups="false" redirectPort="8443" acceptCount="100"
> 	debug="0" connectionTimeout="20000" 
>  	disableUploadTimeout="true" />
> Is the connectionTimeout value the one that might be contributing to this 
> behaviour?
> Are there any other timeout settings that might affect this?
> Thanks!
> Andrzej Jan Taramina
> Chaeron Corporation: Enterprise System Solutions
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> .

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message