I seem to recall, though I couldn't find references to it now, that this could happen if there is a firewall between the RelStorage using processes/threads and your database.
If a long time passes without any activity, this could cause the firewall to forget about the long lived TCP connections that RelStorage keeps, and drop packets silently instead of rejecting them, making the RelStorage end seem hung up. On Thu, Jul 17, 2014 at 4:20 PM, Sean Upton <sdup...@gmail.com> wrote: > Any insights from RelStorage users appreciated on this; > > I have a case where multiple Zope2 instances (each with four threads) > get stuck (most/all threads) waiting on execution of LOCK TABLE > statements (presumably stuck commits) in > relstorage.adapters.locker.PostgreSQLLocker.hold_commit_lock [1]. > > Any ideas on what I should be looking for in PostgreSQL and possible > causes in my application? > > > Sean > > > [1] Call stack via SIGUSR1 to an instance: http://pastie.org/9400704 > _______________________________________________ > For more information about ZODB, see http://zodb.org/ > > ZODB-Dev mailing list - ZODB-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zodb-dev >
_______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
