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 again.
(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 http://www.omnytex.com
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 http://www.chaeron.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
