I'm not sure about servlets myself, but they seem to bring in a new set
of problems, mainly because they all run under one process (as separate
threads). When they die, the socket isn't closed, as the parent process
is still running, etc.
I think this problem isn't necessarily a Java one, as thinking about it,
it could happen to any interface where there is a pool of connections
under one process. Perhaps we should have a time out (say fairly large)
where if the backend is waiting for the client to pull off data, it
closes itself down?
Peter
> -----Original Message-----
> From: Tom Lane [SMTP:tgl@sss.pgh.pa.us]
> Sent: 03 November 1999 06:09
> To: Rich Ryan
> Cc: pgsql-interfaces@postgreSQL.org
> Subject: Re: [INTERFACES] Inifinite socket send from backend to
> java servlet
>
> Rich Ryan <postgres@weblynk.com> writes:
> > I'm running RH Linux 5.2, Jdk 1.1.7v3 on machine A, and RH Linux
> 6.1,
> > postgres 6.5.2 on machine B. Some queries made from A to B never
> return. It
> > looks like the java servlet on machine A skipped out on the query or
> the
> > thread died or got interrupted or something, and machine B is
> infinitely
> > waiting for it to read query results.
>
> I'm not qualified to comment on (nor interested in) the problem with
> the
> java servlets, but I'd say they are pretty buggy if they're dying in
> the
> middle of reading query results.
>
> However, the backend ought to recover gracefully from client failure,
> and if it's not then I'm interested in that.
>
> > I get a ton of these messages...
>
> > FATAL: pq_endmessage failed: errno=32
> > pq_flush: send() failed: Broken pipe
>
> > Within a half day or so, my database connection pool is exhausted
> because
> > there taken up by these infinite waits.
>
> What is supposed to happen is that you get a few of these messages in
> the log while the backend tries to dump out the query results to the
> no-longer-connected client (maybe more than a few of them, if it was a
> big query :-(), and then when the backend finishes the query and tries
> to read the next command from the client, it notices that the client
> connection isn't there anymore, and gracefully exits. Apparently
> you've
> found a combination of circumstances where this doesn't happen like
> it's
> supposed to. I have no immediate ideas about why. Can anyone else
> reproduce this problem?
>
> regards, tom lane
>
> ************
