I am debugging the driver myself, I am looking into the PhantomReferences
that I think may be the cause of the problem (the problem seems to me
loosely related with the garbage collector frequency)

If I do the "set statement_timeout = 60000" on that connection I suppose
that after I release this connection back to the pool and another thread
fetches it the statement timeout will remain set ... is it not?

But it is good to know that I am not crazy....


On 7/12/06, Oliver Jowett <oliver@opencloud.com> wrote:
>
> Lucas Sousa wrote:
>
> > stm.setQueryTimeout( timeout );
>
> > It seems to me that for some (weird) reason, the query timeout is bein
> > achieved without throwing any error or the postgresql driver detecting
> > that.
> >
> > This is some know issue?
>
> Unfortunately setQueryTimeout() is currently a no-op. As a workaround,
> set the server's statement_timeout variable.
>
> > Thread [zzzzzzz:12] (Suspended)
> > SocketInputStream.socketRead0(FileDescriptor, byte[], int, int, int)
> > line: not available [native method]
> > SocketInputStream.read(byte[], int, int) line: not available
> > BufferedInputStream.fill() line: not available
> > BufferedInputStream.read() line: not available
> > PGStream.ReceiveChar() line: 256
> > QueryExecutorImpl.processResults(ResultHandler, int) line: 1164
>
> The driver is waiting for results from the server. Either the query is
> still running or something has got confused about what's happening at
> the protocol level.
>
> Can you reproduce this with loglevel=2 set (as a URL parameter, see the
> driver docs)? Or a tcpdump/snoop/ethereal capture of the connection with
> the server when it gets stuck would also be useful. Also, if you could
> attach to the corresponding backend via gdb or similar and get a stack
> trace that may help.
>
> -O
>