> On 10 Apr 2015, at 9:03 am, Kris Jurka <books@ejurka.com> wrote:
>
>
>
> On Thu, 9 Apr 2015, Royce Ausburn wrote:
>
>> The issue emerged just after we've bumped the max JVM heap size
>> significantly and during a heavy running migration/data transformation
>> process with lots of jdbc queries.
>>
>> The issue appears to be in how processDeadParsedQueries() works - if
>> there're a lot of recently GC'd parsed statements then there'll be a lot of
>> statements to close which manages to fill the send buffer on our end while
>> the corresponding postgres process on the server end is busy filling its
>> send buffer with responses from the close statement requests.
>>
>
> Certainly the driver shouldn't deadlock in this situation and should only
> send a limited number of close requests at once, but if your diagnosis is
> correct that GC is triggering finalization of these resources, it seems
> your application is partly at fault here. If these resources were closed
> when complete instead of relying on GC, they would dissipate at a
> reasonably rate and not cause this deadlock. Perhaps you need to add some
> more close() calls to your code?
>
> Kris Jurka
That's certainly a possibility!
I relayed this along to the engineer and he has already found a few places he isn't closing statements nor result sets!
Thanks very much for pointing this out, I expect that this will resolve the issue better than carefully selecting a
heapsize and praying ;)
--Royce