Hello Colin:
My hypothesis in this case would be that the servlet is encountering some
error during processing of the query or the output processing (which may not
be actually associated with Postgres, hence the query works when you
hardcode it), which causes the servlet to throw an exception, which Tomcat
catches and displays the "Error 500" (I think) page. However, by the time
it sends the error page, the browser has read your
content-disposition/mime-type headers and is attempting to download the
file. Since the error page does not match the file-download format, the
browser never realizes that the page is finished, so appears to hang, and to
make matters worse, you never see the error.
Of course, that's not rocket science; I'm sure you got that far. The task,
I suspect is to track down the error. Here's what I would do:
1- Download and install Log4J from the Jakarta site. You'll be glad you
did, regardless of solving this bug. (Note: Personally I found it had a
bit of a learning curve, probably 1-2 days to figure out your prototype
installation, but once you get past that it's a lifesaver).
2- Add the appropriate cat.debug(...) statements liberally throughout your
servlet code. Don't worry about overdoing it - the neat thing about Log4J
is that unlike System.out.println statements, when you're done debugging,
you just change the Category's priority level and the statements pretty much
turn into no-ops.
3- In particular, make sure you catch any exceptions thrown from your doPost
method and log them. That'll give you the visibility you need on the error.
The download will still fail, but at least you'll have a useful log of what
happened.
I've seen similar errors when I've had Cocoon set up wrong, causing a
request to show an error page when I had set headers to download a file, so
I know that's at least one possible cause.
Cheers,
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.ca
> -----Original Message-----
> From: Colin Freas [mailto:[EMAIL PROTECTED]]
> Sent: April 26, 2002 16:06
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Tomcat, Postgres, JDBC, Blackdown 1.3.1, IE: No impact, no
> idea!
>
>
>
> My application, in a nutshell, allows you to click within a
> series of HTML
> table data cells, and this dynamically creates hidden input
> boxes on a form,
> which when submitted, the server processes into SQL, and
> returns the result
> of.
>
> The problem: 'selecting' too many data cells causes the site
> to skip the
> lengthy db query (which normally takes at least 3 minutes,) and it
> immediately returns the results as a downloadable file (set up using
> res.setContentType & setHeader.) It then churns away
> downloading this file
> indefinitely. Select only a few data cells, and you get a
> nicely formatted
> comma-delimited set of data in a text file, after 3-10
> minutes... the table
> has tens of millions of rows.
>
> The log files haven't helped me much. The servlet I believe
> to be causing
> the problem is called from a form's post action (Is there a
> limit on header
> sizes with post?,) but there is no record of a call to it in
> the access log
> when this error occurs. It is clearly being run at least
> partially, though.
> I can see a log entry I submit from within the offending servlet to
> localhost_log for the final SQL statement that it should be
> submitting to
> the Postgres database, and also a localhost_log entry for
> representing the
> number of cells that have been selected.
>
> The error is reproducable, but it doesn't appear to be an
> absolute number of
> cells selected, or an inherent problem with the SQL
> statement, or the length
> of the SQL statement. If you're familar with Postgres, I've
> used psql to
> run the generated SQL, and it works perfectly, although the
> statement takes
> something like 8 to 10 minutes to run. And I've set up
> Postgres to log all
> queries, and it definitely starts processing the query; but
> when the error
> occurs I get a response immediately, and it's empty.
>
> Thinking it might be a JDBC error, I wrote a simple test page
> which submits
> a SQL statement I know causes this error as a string directly
> through a
> Statement.executeQuery. Alas, after the correct amount of
> time, it presents
> a page with the correct results.
>
> myWitsI'm
>
> I don't suspect this is a bug, and I realize it could be
> Tomcat, Postgres,
> JDBC, or IE for all that, but I figure I'd start here.
>
> Any ideas or thoughts are welcome and appreciated.
>
> Colin Freas
> Systems Analyst
> Center for Population and Health
> Georgetown University
>
>
> --
> 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]>
