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 .
> Any ideas on what I should be looking for in PostgreSQL and possible
> causes in my application?
>  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
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org