Re: [Sks-devel] DB_INIT_LOCK problems?

[Yaron Minsky]

My problem is that I don't understand why there are ever deadlocks at
all.  Both "sks db" and "sks recon" are single-threaded applications. 
They communicate with each other in various ways, but they don't
access each other's databases at all.  So the fact that there are ever
deadlocks of any sort suggests to me that my code is doing something
that's just wrong.  I'd prefer to figure out what that is before
making the code as it is more robust to being interrupted by the
deadlock avoider.

That said, I've looked at this a few times, and haven't been able to
figure out what I'm actually doing wrong.  So if you have any thoughts
I'm all ears.

y

On Sun, 25 Jul 2004 14:59:12 -0400, Jason Harris <address@hidden> wrote:
> On Sat, Jul 24, 2004 at 06:03:33PM -0400, Jason Harris wrote:
> > On Fri, Jul 23, 2004 at 08:25:02PM -0400, Jason Harris wrote:
> 
> > Well, deadlock is hazardous to SKS - both "sks db" and "sks recon"
> > were wedged by this (TZ=UTC):
> >
> >   2004-07-24 21:31:51 Del'ng hash 94318B9CBA39316D1B1E95E83E1E1AA0
> >   2004-07-24 21:31:51 Adding hash F7CAD50EFFDC22AA0C7F6FDE721BFC61
> >   2004-07-24 21:33:22 Fatal database error: Bdb.DBError("caml_db_put: 
> > DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock")
> >   2004-07-24 21:33:22 Key addition failed: Eventloop.SigAlarm
> >   2004-07-24 21:33:22 Handling /pks/hashquery
> 
> [another self-reply...]
> 
> Enabling lock and transaction timeouts might be a workable solution.
> With this file in both the KDB and PTree directories:
> 
>   %cat DB_CONFIG
>   set_flags DB_LOG_AUTOREMOVE
>   set_lock_timeout 1000
>   set_txn_timeout 1000
> 
> and "db_deadlock -t 1.0 -a e" running from/on the KDB directory/
> environment, SKS didn't wedge when a deadlock was broken and was
> able to update a key during a later gossip run (TZ=UTC):
> 
> 2004-07-25 18:20:05 1 potential merges found for keyid 56A5C195
> 2004-07-25 18:20:05 2 updates found before filtering
> 2004-07-25 18:20:05 Applying 2 changes
> 2004-07-25 18:20:05 Adding hash 87173750DD20A796D2FFF0F22B9AA888
> 2004-07-25 18:20:05 Del'ng hash 8C61CE335044BCC376BCB0696C3E213E
> 2004-07-25 18:20:05 Fatal database error: Bdb.DBError("caml_db_put: 
> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock")
> 2004-07-25 18:20:05 Key addition failed: Sys.Break
> 2004-07-25 18:20:14 Handling /pks/hashquery
> 2004-07-25 18:20:14 1 keys found
> 2004-07-25 18:21:56 Handling /pks/hashquery
> 2004-07-25 18:21:59 1 keys found
> 2004-07-25 18:22:07 Fatal database error: Bdb.DBError("caml_db_get: 
> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock")
> 2004-07-25 18:22:07 add_keys_merge failed: Sys.Break
> 2004-07-25 18:22:07 Key addition failed: Sys.Break
> 2004-07-25 18:23:05 Fatal database error: Bdb.DBError("caml_db_get: 
> DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock")
> 2004-07-25 18:23:05 add_keys_merge failed: Sys.Break
> 2004-07-25 18:23:05 Key addition failed: Sys.Break
> 2004-07-25 18:23:17 Handling /pks/hashquery
> 2004-07-25 18:23:17 1 keys found
> 2004-07-25 18:24:55 1 potential merges found for keyid 56A5C195
> 2004-07-25 18:24:55 2 updates found before filtering
> 2004-07-25 18:24:55 Applying 2 changes
> 2004-07-25 18:24:55 Adding hash 87173750DD20A796D2FFF0F22B9AA888
> 2004-07-25 18:24:55 Del'ng hash 8C61CE335044BCC376BCB0696C3E213E
> 2004-07-25 18:24:58 Handling /pks/hashquery
> 2004-07-25 18:24:58 Error fetching key from hash 
> 8C61CE335044BCC376BCB0696C3E213E: Not_found
> 2004-07-25 18:24:58 0 keys found
> 
> Other than occasionally losing direct HKP submissions and/or possibly
> failing to queue email sync. messages, do you anticipate any problems
> with this workaround, Yaron?
> 
> 
> 
> --
> Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
> address@hidden _|_ web:  http://keyserver.kjsl.com/~jharris/
>           Got photons?   (TM), (C) 2004
> 
> 
>