[elephant-devel] BDB Run recovery errors seen after switching to ELEPHANT-1-0-A2

Yarek Kowalik yarek.kowalik at gmail.com
Tue Mar 10 23:17:39 UTC 2009


Tried with an empty store and :register flag set to T. I get the same error.


Hmm...

Yarek

On Tue, Mar 10, 2009 at 4:11 PM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:

> I've set the ':register t' but that does not seem to have an effect. I am
> now going to try with a completely empty store directory to see if that
> makes a difference (maybe new elephant didn't like old data).
>
> Yarek
>
>
> On Tue, Mar 10, 2009 at 3:57 PM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:
>
>> Hi Ian,
>>
>> Thanks for replying.
>>
>> The only difference on my end between Jan version and now is the version
>> of Elephant. I can switch back to the unstable version and the current app
>> works fine.
>>
>> Re: slots on the controler: all are set to some value - none are unbound,
>> but some are (see below).
>>
>> THe only reason I was upgrading was do to some other erros seen with
>> map-inverted-index that returned nils (though there is a way to do a cleanup
>> of those).
>>
>> I hope that Leslie can shed more light. Is there a way to set the
>> 'regsiter' flag?
>>
>> Yarek
>>
>>
>> #<DB-BDB::BDB-STORE-CONTROLLER {10024ADF61}>
>> --------------------
>> Class: #<STANDARD-CLASS DB-BDB::BDB-STORE-CONTROLLER>
>> --------------------
>> All Slots:
>> BTREES                 = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X006417A0
>> :TYPE (* T)> [set value] [make unbound]
>> CID-SEQ                = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X006439A0
>> :TYPE (* T)> [set value] [make unbound]
>> DB                     = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X00641060
>> :TYPE (* T)> [set value] [make unbound]
>> DB-VERSION             = 100 [set value] [make unbound]
>> DEADLOCK-DETECT-THREAD = NIL [set value] [make unbound]
>> DEADLOCK-PID           = NIL [set value] [make unbound]
>> DESERIALIZE            = ELEPHANT-SERIALIZER2::DESERIALIZE [set value]
>> [make unbound]
>> DESERIALIZE-FN         = #<FUNCTION (SB-C::&OPTIONAL-DISPATCH ..)> [set
>> value] [make unbound]
>> DUP-BTREES             = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X00641EE0
>> :TYPE (* T)> [set value] [make unbound]
>> ENVIRONMENT            = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X0063F320
>> :TYPE (* T)> [set value] [make unbound]
>> GC-MARK-LIST           = NIL [set value] [make unbound]
>> GC-MARK-TABLE          = NIL [set value] [make unbound]
>> GC-MARKING-P           = NIL [set value] [make unbound]
>> GC-MAX-OID             = NIL [set value] [make unbound]
>> INDEX-TABLE            = #<BDB-BTREE oid:-2> [set value] [make unbound]
>> INDICES                = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X00642620
>> :TYPE (* T)> [set value] [make unbound]
>> INDICES-ASSOC          = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X00642D60
>> :TYPE (* T)> [set value] [make unbound]
>> INSTANCE-CACHE         = #<HASH-TABLE :TEST EQL :COUNT 8 {100271C671}>
>> [set value] [make unbound]
>> INSTANCE-CACHE-LOCK    = #S(SB-THREAD:MUTEX :NAME NIL :%OWNER NIL :STATE
>> 0) [set value] [make unbound]
>> INSTANCE-CLASS-INDEX   = #<BDB-BTREE-INDEX oid:1> [set value] [make
>> unbound]
>> INSTANCE-TABLE         = #<BDB-INDEXED-BTREE oid:-3> [set value] [make
>> unbound]
>> METADATA               = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X006409B0
>> :TYPE (* T)> [set value] [make unbound]
>> OID-DB                 = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X006434E0
>> :TYPE (* T)> [set value] [make unbound]
>> OID-SEQ                = #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #X00643B70
>> :TYPE (* T)> [set value] [make unbound]
>> ROOT                   = #<BDB-BTREE oid:-1> [set value] [make unbound]
>> SCHEMA-CACHE           = #<HASH-TABLE :TEST EQ :COUNT 0 {100271C561}> [set
>> value] [make unbound]
>> SCHEMA-CACHE-LOCK      = #S(SB-THREAD:MUTEX :NAME NIL :%OWNER NIL :STATE
>> 0) [set value] [make unbound]
>> SCHEMA-CLASSES         = NIL [set value] [make unbound]
>> SCHEMA-NAME-INDEX      = #<BDB-BTREE-INDEX oid:0> [set value] [make
>> unbound]
>> SCHEMA-TABLE           = #<BDB-INDEXED-BTREE oid:-4> [set value] [make
>> unbound]
>> SERIALIZE              = ELEPHANT-SERIALIZER2::SERIALIZE [set value] [make
>> unbound]
>> SERIALIZE-FN           = #<FUNCTION ELEPHANT-SERIALIZER2::SERIALIZE> [set
>> value] [make unbound]
>> SERIALIZER-VERSION     = 2 [set value] [make unbound]
>> SPEC                   = (:BDB "/home/yarek/lisp/projects/zzz/data/store/"
>> :RECOVER NIL) [set value] [make unbound]
>>
>>
>>
>>
>>
>> On Tue, Mar 10, 2009 at 2:50 PM, Ian Eslick <eslick at media.mit.edu> wrote:
>>
>>> Unfortunately that's not a highly informative backtrace.  Did you
>>> upgrade to the latest, and this caused it, or did something suddenly
>>> change that caused the January '09 version to work?
>>>
>>> Some possible sources of these problems:
>>>
>>> 1) Somehow the 'register' flag that helps support multiple processes
>>> is causing problems; it is no longer set by default I believe.
>>> (Leslie may know more)
>>>
>>> 2) The store-controller is not being opened properly.  Are all the
>>> slots set in the controller after the second process is opened?
>>>
>>> Can you be more specific about what changed between January and now?
>>>
>>> Ian
>>>
>>> On Mar 10, 2009, at 5:31 PM, Yarek Kowalik wrote:
>>>
>>> > Hi folks,
>>> >
>>> > I have two processes accessing the same BDB.  One process manages
>>> > weblocks requests on port 80, the other on port 443. In the elephant
>>> > from last January, I was able to start, connect and use BDB from
>>> > both processes.  Now, when I the user is redirected to port 443 and
>>> > the process tries to retrieve data from the BDB, I get a
>>> > DB_RUNRECOVERY error (see trace below).   This happens when the port
>>> > 443 porcess connects for the very first time to BDB.
>>> >
>>> > I think I have seen this before, and I think it had to do with some
>>> > default configuration on the controler, some argument  that forced
>>> > the BDB into the recovery mode when process first starts up.
>>> >
>>> > Any idea how to resolve this? It's killing my secure connection on
>>> > my web app - it's urgent.
>>> >
>>> > Thanks,
>>> >
>>> > Yarek
>>> >
>>> >
>>> >
>>> > Berkeley DB error #-30974: DB_RUNRECOVERY: Fatal error, run database
>>> > recovery
>>> >    [Condition of type ELEPHANT:BDB-DB-ERROR]
>>> >
>>> > Restarts:
>>> >  0: [TERMINATE-THREAD] Terminate this thread (#<THREAD "hunchentoot-
>>> > worker-6" RUNNING {B6CD101}>)
>>> >
>>> > Backtrace:
>>> >   0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA
>>> > #) {AD4FBA5}>)
>>> >   1: (SWANK::DEBUG-IN-EMACS #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)
>>> >   2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
>>> > SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {B729FED}>)
>>> >   3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {AF23819}>
>>> > #<CLOSURE (LAMBDA #) {B729FFD}>)
>>> >   4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {AF23819}>
>>> > #<CLOSURE (LAMBDA #) {B729FED}>)
>>> >   5: (SWANK:INVOKE-SLIME-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)
>>> >   6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
>>> > SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {B729FCD}>)
>>> >   7: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)
>>> >   8: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)[:EXTERNAL]
>>> >   9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))
>>> > #<unavailable argument> #<unavailable argument> #<ELEPHANT:BDB-DB-
>>> > ERROR {B729BF9}>)
>>> >  10: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)[:EXTERNAL]
>>> >  11: (ERROR #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)[:EXTERNAL]
>>> >  12: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)
>>> >  13: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)[:EXTERNAL]
>>> >  14: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {B729BF9}>)[:EXTERNAL]
>>> >  15: (ERROR ELEPHANT:BDB-DB-ERROR)[:EXTERNAL]
>>> >       Locals:
>>> >         SB-DEBUG::ARG-0 = 3
>>> >         SB-DEBUG::ARG-1 = ELEPHANT:BDB-DB-ERROR
>>> >  16: ((SB-PCL::FAST-METHOD ELEPHANT:GET-VALUE (T DB-BDB::BDB-BTREE))
>>> > #<unavailable lambda list>)
>>> >       [No Locals]
>>> >  17: (ELEPHANT::ENSURE-SLOT-DEF-INDEX #<unavailable argument>
>>> > #<unavailable argument>)
>>> >       Locals:
>>> >         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>> >  18: ((SB-PCL::FAST-METHOD ELEPHANT:FIND-INVERTED-INDEX
>>> > (ELEPHANT:PERSISTENT-METACLASS T)) #<unavailable argument>
>>> > #<unavailable argument> #<unavailable argument> #<unavailable
>>> > argument>)[:EXTERNAL]
>>> >       Locals:
>>> >         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-3 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-4 = :<NOT-AVAILABLE>
>>> >  19: (ELEPHANT:MAP-INVERTED-INDEX #<unavailable argument>
>>> > #<unavailable argument> #<unavailable argument>)[:EXTERNAL]
>>> >       Locals:
>>> >         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>>> >         SB-DEBUG::ARG-3 = :<NOT-AVAILABLE>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > elephant-devel site list
>>> > elephant-devel at common-lisp.net
>>> > http://common-lisp.net/mailman/listinfo/elephant-devel
>>>
>>>
>>> _______________________________________________
>>> elephant-devel site list
>>> elephant-devel at common-lisp.net
>>> http://common-lisp.net/mailman/listinfo/elephant-devel
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20090310/1dbe2251/attachment.html>


More information about the elephant-devel mailing list