Re: Bug report: TCP deadlock between JDBC & Postgres
От | Royce Ausburn |
---|---|
Тема | Re: Bug report: TCP deadlock between JDBC & Postgres |
Дата | |
Msg-id | D6C00A06-4DD6-4CE9-B7D2-D3C0F4482549@inomial.com обсуждение исходный текст |
Ответ на | Re: Bug report: TCP deadlock between JDBC & Postgres (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
> 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
В списке pgsql-jdbc по дате отправления: