From yarek.kowalik at gmail.com  Tue Mar  3 01:28:26 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Mon, 2 Mar 2009 17:28:26 -0800
Subject: [elephant-devel] map-inverted index returns list with nil values
Message-ID: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>

I have a strange situation.  I get inconsistent results when using
get-instances-by-class and map-inverted-index.  The first one is correct,
the second one returns a bunch of NILs in the list in addition to the
correct results.  Is this a bug or an expected result?  Here are my commands
and output:

> (elephant:get-instances-by-class 'product-set)
(#<PRODUCT-SET oid:27002> #<PRODUCT-SET oid:67705>)
> (elephant:map-inverted-index #'ele::identity2 'product-set 'rank :collect
t)
(#<PRODUCT-SET oid:27002> #<PRODUCT-SET oid:67705> NIL NIL NIL NIL NIL NIL
NIL
 NIL)

For some strange reason I get OIDs that should be dead:

> (elephant:map-inverted-index #'ele::identity2 'product-set 'rank :collect
t :oids t)
(27002 67705 58702 58704 58705 58707 58708 58709 58710 58711)

Any idea what's going on and how this could have happened?

Is there a way of clearing OIDs for which I get NILs?

Note: I'm using code pulled from unstable branch at 2008-12-05 21:29.

Thanks in advance,

Yarek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20090302/e2776083/attachment.html>

From robo4288 at gmail.com  Tue Mar  3 02:28:13 2009
From: robo4288 at gmail.com (Robert Boone)
Date: Mon, 2 Mar 2009 20:28:13 -0600
Subject: [elephant-devel] Possible problem with my setup...
Message-ID: <435624390903021828w5bb5019fme4337d133564790@mail.gmail.com>

After making many mistakes I finally got elephant to build using
berkley db 4.7. I have run across a problem that I hope someone can
help me with.
The first time I try to make a persistent it fails with this error:

There is no class named MY-PERSISTENT-CLASS.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [RETRY] Retry SLIME interactive evaluation request.
 1: [ABORT] Return to SLIME's top level.
 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker"
RUNNING {121EECC9}>)

If I choose retry everything works the way it should. Am I doing
something wrong? This is the configuration I used to build elephant:

;; OSX Defaults
#+(and (or sbcl allegro openmcl lispworks) (not (or mswindows windows
win32)) (or macosx darwin))
((:compiler . :gcc)
(:berkeley-db-version . "4.7")
(:berkeley-db-include-dir . "/opt/local/include/db47")
(:berkeley-db-lib-dir . "/opt/local/lib/db47")
(:berkeley-db-lib . "/opt/local/lib/db47/libdb-4.7.dylib")
(:berkeley-db-deadlock . "/opt/local/bin/db47_deadlock")
(:berkeley-db-cachesize . 20971520)
(:berkeley-db-max-locks . 2000)
(:berkeley-db-max-objects . 2000)
(:berkeley-db-map-degree2 . t)
(:berkeley-db-mvcc . nil)
(:clsql-lib-paths . nil)
(:prebuilt-libraries . nil))


I'm using sbcl 1.0.25 with threads on Mac OS X compiled from source.

Any clue to what I'm doing wrong will be helpful.

Robert



From yarek.kowalik at gmail.com  Tue Mar  3 03:31:05 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Mon, 2 Mar 2009 19:31:05 -0800
Subject: [elephant-devel] map-inverted index returns list with nil values
In-Reply-To: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>
References: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>
Message-ID: <ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>

To fix this, I run

(elephant:find-inverted-index 'product-set 'rank)

But I still don't understand how this could have happened. My guess is that
it may have to do with adding the 'rank slot recently has confused the index
somehow.  I don't know how.

Yarek

On Mon, Mar 2, 2009 at 5:28 PM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:

>
> I have a strange situation.  I get inconsistent results when using
> get-instances-by-class and map-inverted-index.  The first one is correct,
> the second one returns a bunch of NILs in the list in addition to the
> correct results.  Is this a bug or an expected result?  Here are my commands
> and output:
>
> > (elephant:get-instances-by-class 'product-set)
> (#<PRODUCT-SET oid:27002> #<PRODUCT-SET oid:67705>)
> > (elephant:map-inverted-index #'ele::identity2 'product-set 'rank :collect
> t)
> (#<PRODUCT-SET oid:27002> #<PRODUCT-SET oid:67705> NIL NIL NIL NIL NIL NIL
> NIL
>  NIL)
>
> For some strange reason I get OIDs that should be dead:
>
> > (elephant:map-inverted-index #'ele::identity2 'product-set 'rank :collect
> t :oids t)
> (27002 67705 58702 58704 58705 58707 58708 58709 58710 58711)
>
> Any idea what's going on and how this could have happened?
>
> Is there a way of clearing OIDs for which I get NILs?
>
> Note: I'm using code pulled from unstable branch at 2008-12-05 21:29.
>
> Thanks in advance,
>
> Yarek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20090302/c24ed889/attachment.html>

From sky at viridian-project.de  Tue Mar  3 09:27:11 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Tue, 3 Mar 2009 10:27:11 +0100 (CET)
Subject: [elephant-devel] map-inverted index returns list with nil values
In-Reply-To: <ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>
References: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>
	<ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>
Message-ID: <ee2b127a487ba3aef966df8a1299b620.squirrel@mail.stardawn.org>


> To fix this, I run
>
> (elephant:find-inverted-index 'product-set 'rank)
>
> But I still don't understand how this could have happened. My guess is that
> it may have to do with adding the 'rank slot recently has confused the index
> somehow.  I don't know how.

I have spotted similar problems starting with 091 (the first version of
Elephant I used) but could never pinpoint them.

I suggest that like me you upgrade to the current Elephant 1.0 as a
next step to make sure that this hasn't been fixed in the meantime.

After that we could add basic index sanity checks in the slot index code
to find the source of the error.

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From sky at viridian-project.de  Tue Mar  3 09:28:14 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Tue, 3 Mar 2009 10:28:14 +0100 (CET)
Subject: [elephant-devel] Possible problem with my setup...
In-Reply-To: <435624390903021828w5bb5019fme4337d133564790@mail.gmail.com>
References: <435624390903021828w5bb5019fme4337d133564790@mail.gmail.com>
Message-ID: <baaad357fcc63afba41d23a1db328e80.squirrel@mail.stardawn.org>


> After making many mistakes I finally got elephant to build using
> berkley db 4.7.

For the record, what kind of mistakes?


> Restarts:
>  0: [RETRY] Retry SLIME interactive evaluation request.
>  1: [ABORT] Return to SLIME's top level.
>  2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker"
> RUNNING {121EECC9}>)
>
> If I choose retry everything works the way it should. Am I doing
> something wrong? This is the configuration I used to build elephant:

This doesn't look like a configuration issue to me.

Can you show us your code?

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From eslick at media.mit.edu  Tue Mar  3 11:48:14 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 3 Mar 2009 06:48:14 -0500
Subject: [elephant-devel] map-inverted index returns list with nil values
In-Reply-To: <ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>
References: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>
	<ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>
Message-ID: <4B848B36-BF9E-4224-B8A4-8D14FB1F4C94@media.mit.edu>

You should upgrade to elephant-1.0.  There was a bug on unstable,  
which I no longer update, that under certain circumstances would fail  
to delete instances from indices while they were deleted from the  
instance index.

Ian

On Mar 2, 2009, at 10:31 PM, Yarek Kowalik wrote:

> To fix this, I run
>
> (elephant:find-inverted-index 'product-set 'rank)
>
> But I still don't understand how this could have happened. My guess  
> is that it may have to do with adding the 'rank slot recently has  
> confused the index somehow.  I don't know how.
>
> Yarek
>
> On Mon, Mar 2, 2009 at 5:28 PM, Yarek Kowalik  
> <yarek.kowalik at gmail.com> wrote:
>
> I have a strange situation.  I get inconsistent results when using  
> get-instances-by-class and map-inverted-index.  The first one is  
> correct, the second one returns a bunch of NILs in the list in  
> addition to the correct results.  Is this a bug or an expected  
> result?  Here are my commands and output:
>
> > (elephant:get-instances-by-class 'product-set)
> (#<PRODUCT-SET oid:27002> #<PRODUCT-SET oid:67705>)
> > (elephant:map-inverted-index #'ele::identity2 'product-set  
> 'rank :collect t)
> (#<PRODUCT-SET oid:27002> #<PRODUCT-SET oid:67705> NIL NIL NIL NIL  
> NIL NIL NIL
>  NIL)
>
> For some strange reason I get OIDs that should be dead:
>
> > (elephant:map-inverted-index #'ele::identity2 'product-set  
> 'rank :collect t :oids t)
> (27002 67705 58702 58704 58705 58707 58708 58709 58710 58711)
>
> Any idea what's going on and how this could have happened?
>
> Is there a way of clearing OIDs for which I get NILs?
>
> Note: I'm using code pulled from unstable branch at 2008-12-05 21:29.
>
> Thanks in advance,
>
> Yarek
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




From eslick at media.mit.edu  Tue Mar  3 11:52:31 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 3 Mar 2009 06:52:31 -0500
Subject: [elephant-devel] map-inverted index returns list with nil values
In-Reply-To: <ee2b127a487ba3aef966df8a1299b620.squirrel@mail.stardawn.org>
References: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>
	<ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>
	<ee2b127a487ba3aef966df8a1299b620.squirrel@mail.stardawn.org>
Message-ID: <FB9AEEC2-A0A3-4671-A9D9-327296F6D74C@media.mit.edu>

There is an internal function (elephant::rebuild-slot-index 'class  
'index) which will clean up your indices after an upgrade.

Ian

On Mar 3, 2009, at 4:27 AM, Leslie P. Polzer wrote:

>
>> To fix this, I run
>>
>> (elephant:find-inverted-index 'product-set 'rank)
>>
>> But I still don't understand how this could have happened. My guess  
>> is that
>> it may have to do with adding the 'rank slot recently has confused  
>> the index
>> somehow.  I don't know how.
>
> I have spotted similar problems starting with 091 (the first version  
> of
> Elephant I used) but could never pinpoint them.
>
> I suggest that like me you upgrade to the current Elephant 1.0 as a
> next step to make sure that this hasn't been fixed in the meantime.
>
> After that we could add basic index sanity checks in the slot index  
> code
> to find the source of the error.
>
>  Leslie
>
> -- 
> LinkedIn Profile: http://www.linkedin.com/in/polzer
> Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
> Blog: http://blog.viridian-project.de/
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




From eslick at media.mit.edu  Tue Mar  3 11:53:52 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 3 Mar 2009 06:53:52 -0500
Subject: [elephant-devel] Possible problem with my setup...
In-Reply-To: <435624390903021828w5bb5019fme4337d133564790@mail.gmail.com>
References: <435624390903021828w5bb5019fme4337d133564790@mail.gmail.com>
Message-ID: <BBB3ED0C-100F-4232-8597-3C5C465D50AC@media.mit.edu>

I had problems running with threads on Mac OS X, but I don't think  
this is the problem your having.  I assume you're using elephant-1.0?

Can you give us the simplest possible test case?  i.e. load elephant,  
open-controller, then evaluate a defpclass form?

Thank you,
Ian

On Mar 2, 2009, at 9:28 PM, Robert Boone wrote:

> After making many mistakes I finally got elephant to build using
> berkley db 4.7. I have run across a problem that I hope someone can
> help me with.
> The first time I try to make a persistent it fails with this error:
>
> There is no class named MY-PERSISTENT-CLASS.
>   [Condition of type SIMPLE-ERROR]
>
> Restarts:
> 0: [RETRY] Retry SLIME interactive evaluation request.
> 1: [ABORT] Return to SLIME's top level.
> 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "worker"
> RUNNING {121EECC9}>)
>
> If I choose retry everything works the way it should. Am I doing
> something wrong? This is the configuration I used to build elephant:
>
> ;; OSX Defaults
> #+(and (or sbcl allegro openmcl lispworks) (not (or mswindows windows
> win32)) (or macosx darwin))
> ((:compiler . :gcc)
> (:berkeley-db-version . "4.7")
> (:berkeley-db-include-dir . "/opt/local/include/db47")
> (:berkeley-db-lib-dir . "/opt/local/lib/db47")
> (:berkeley-db-lib . "/opt/local/lib/db47/libdb-4.7.dylib")
> (:berkeley-db-deadlock . "/opt/local/bin/db47_deadlock")
> (:berkeley-db-cachesize . 20971520)
> (:berkeley-db-max-locks . 2000)
> (:berkeley-db-max-objects . 2000)
> (:berkeley-db-map-degree2 . t)
> (:berkeley-db-mvcc . nil)
> (:clsql-lib-paths . nil)
> (:prebuilt-libraries . nil))
>
>
> I'm using sbcl 1.0.25 with threads on Mac OS X compiled from source.
>
> Any clue to what I'm doing wrong will be helpful.
>
> Robert
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




From sky at viridian-project.de  Tue Mar  3 12:19:29 2009
From: sky at viridian-project.de (Leslie P. Polzer)
Date: Tue, 3 Mar 2009 13:19:29 +0100 (CET)
Subject: [elephant-devel] map-inverted index returns list with nil values
In-Reply-To: <FB9AEEC2-A0A3-4671-A9D9-327296F6D74C@media.mit.edu>
References: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>
	<ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>
	<ee2b127a487ba3aef966df8a1299b620.squirrel@mail.stardawn.org>
	<FB9AEEC2-A0A3-4671-A9D9-327296F6D74C@media.mit.edu>
Message-ID: <244044d7d1b3ade80b87d8c3bca4cd6c.squirrel@mail.stardawn.org>


> There is an internal function (elephant::rebuild-slot-index 'class
> 'index) which will clean up your indices after an upgrade.

Actually it's part of the external interface.

So you think that index artifacts can only be the result of
an Elephant upgrade?

  Leslie

-- 
LinkedIn Profile: http://www.linkedin.com/in/polzer
Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
Blog: http://blog.viridian-project.de/




From eslick at media.mit.edu  Tue Mar  3 14:15:05 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 3 Mar 2009 09:15:05 -0500
Subject: [elephant-devel] map-inverted index returns list with nil values
In-Reply-To: <244044d7d1b3ade80b87d8c3bca4cd6c.squirrel@mail.stardawn.org>
References: <ecb948b30903021728y3f41def0w564422b4e79b0026@mail.gmail.com>
	<ecb948b30903021931ve9319e1kebd395a1ba4c4335@mail.gmail.com>
	<ee2b127a487ba3aef966df8a1299b620.squirrel@mail.stardawn.org>
	<FB9AEEC2-A0A3-4671-A9D9-327296F6D74C@media.mit.edu>
	<244044d7d1b3ade80b87d8c3bca4cd6c.squirrel@mail.stardawn.org>
Message-ID: <75618815-EA93-4551-8BF6-8A6234DC3321@media.mit.edu>

No, it was a bug that was fixed in Dec/Jan on elephant-1.0

Ian

On Mar 3, 2009, at 7:19 AM, Leslie P. Polzer wrote:

>
>> There is an internal function (elephant::rebuild-slot-index 'class
>> 'index) which will clean up your indices after an upgrade.
>
> Actually it's part of the external interface.
>
> So you think that index artifacts can only be the result of
> an Elephant upgrade?
>
>  Leslie
>
> -- 
> LinkedIn Profile: http://www.linkedin.com/in/polzer
> Xing Profile: https://www.xing.com/profile/LeslieP_Polzer
> Blog: http://blog.viridian-project.de/
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




From yarek.kowalik at gmail.com  Tue Mar 10 21:31:01 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Tue, 10 Mar 2009 14:31:01 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching to
	ELEPHANT-1-0-A2
Message-ID: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>

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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/elephant-devel/attachments/20090310/47fa8485/attachment.html>

From eslick at media.mit.edu  Tue Mar 10 21:50:25 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 10 Mar 2009 17:50:25 -0400
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
Message-ID: <207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>

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




From yarek.kowalik at gmail.com  Tue Mar 10 22:57:42 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Tue, 10 Mar 2009 15:57:42 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
Message-ID: <ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>

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/163ace74/attachment.html>

From yarek.kowalik at gmail.com  Tue Mar 10 23:11:10 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Tue, 10 Mar 2009 16:11:10 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
Message-ID: <ecb948b30903101611j41b4fdb7mfd1793540192a3a@mail.gmail.com>

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/6cf58cf0/attachment.html>

From yarek.kowalik at gmail.com  Tue Mar 10 23:17:39 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Tue, 10 Mar 2009 16:17:39 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903101611j41b4fdb7mfd1793540192a3a@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<ecb948b30903101611j41b4fdb7mfd1793540192a3a@mail.gmail.com>
Message-ID: <ecb948b30903101617j275e5ae0g45a942239b03bd89@mail.gmail.com>

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>

From eslick at media.mit.edu  Tue Mar 10 23:20:38 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 10 Mar 2009 19:20:38 -0400
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
Message-ID: <6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>

You're using BDB 4.7, right?  What machine, os, word-width, etc?

Add :register t and :recover t to the open-store keyword list.

You can also try downloading from the elephant-1.0 repo but using:

darcs get --tag=ELEPHANT-1-0-A2 http://www.common-lisp.net/project/elephant/darcs/elephant-1.0

Ian




On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




From eslick at media.mit.edu  Wed Mar 11 00:00:31 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Tue, 10 Mar 2009 20:00:31 -0400
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903101611j41b4fdb7mfd1793540192a3a@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<ecb948b30903101611j41b4fdb7mfd1793540192a3a@mail.gmail.com>
Message-ID: <AF38F3D7-E2D9-493B-A011-77009D3F6B5A@media.mit.edu>

I did optimize BDB a bit, so it's possible that one of those  
optimizations has caused a problem.  Try going back to tag 1-0-A2 or  
using the latest if you're already using the tagged version and see if  
there is a difference.

Sorry for the delay, cl.net seems to hold up my e-mail for awhile  
before forwarding it along.

Ian

On Mar 10, 2009, at 7:11 PM, Yarek Kowalik 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
>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




From yarek.kowalik at gmail.com  Wed Mar 11 17:06:32 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Wed, 11 Mar 2009 10:06:32 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
Message-ID: <ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>

Info:

- BDB 4.7.
- Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is using) and 64
bit (AMD X2 64) versions.
- got the ELEPHANT-1-0-A2 via darcs

I'm trying out the :register t and :recover t options now.

Yarek

On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu> wrote:

> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>
> Add :register t and :recover t to the open-store keyword list.
>
> You can also try downloading from the elephant-1.0 repo but using:
>
> darcs get --tag=ELEPHANT-1-0-A2
> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>
> Ian
>
>
>
>
> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
> >
> > _______________________________________________
> > 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/20090311/4684b12a/attachment.html>

From yarek.kowalik at gmail.com  Wed Mar 11 17:28:50 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Wed, 11 Mar 2009 10:28:50 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
	<ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
Message-ID: <ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>

Ok so that did not work.

I remember that last time I had to remove :recover t from OPEN-STORE method
in weblocks/src/store/elephant/elephant.lisp since that was the source of
problems with opening a store with two processes.  I think it forces the
recovery mode at connection startup.

I wonder if I should try :recover nil :register t -- doing that now.

Yarek

On Wed, Mar 11, 2009 at 10:06 AM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:

> Info:
>
> - BDB 4.7.
> - Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is using) and
> 64 bit (AMD X2 64) versions.
> - got the ELEPHANT-1-0-A2 via darcs
>
> I'm trying out the :register t and :recover t options now.
>
> Yarek
>
>
> On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu> wrote:
>
>> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>>
>> Add :register t and :recover t to the open-store keyword list.
>>
>> You can also try downloading from the elephant-1.0 repo but using:
>>
>> darcs get --tag=ELEPHANT-1-0-A2
>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>
>> Ian
>>
>>
>>
>>
>> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
>> >
>> > _______________________________________________
>> > 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/20090311/02a5938f/attachment.html>

From eslick at media.mit.edu  Wed Mar 11 17:38:16 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Wed, 11 Mar 2009 13:38:16 -0400
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
	<ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
	<ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>
Message-ID: <BB4CE71B-360F-424D-A43F-BCBCE0DD7EEA@media.mit.edu>

BDB docs state that :register t :recover t solve the multi-process  
recover problem.  If you have already registered a process, it will  
inhibit recovery when a second process connects.

I have another user with a deserialization error problem.  Try  
updating to the latest elephant-1.0 and you should see an updated  
deserialization-error report in the backtrace that tells you more  
about why there was an error.

Ian

On Mar 11, 2009, at 1:28 PM, Yarek Kowalik wrote:

> Ok so that did not work.
>
> I remember that last time I had to remove :recover t from OPEN-STORE  
> method in weblocks/src/store/elephant/elephant.lisp since that was  
> the source of problems with opening a store with two processes.  I  
> think it forces the recovery mode at connection startup.
>
> I wonder if I should try :recover nil :register t -- doing that now.
>
> Yarek
>
> On Wed, Mar 11, 2009 at 10:06 AM, Yarek Kowalik <yarek.kowalik at gmail.com 
> > wrote:
> Info:
>
> - BDB 4.7.
> - Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is  
> using) and 64 bit (AMD X2 64) versions.
> - got the ELEPHANT-1-0-A2 via darcs
>
> I'm trying out the :register t and :recover t options now.
>
> Yarek
>
>
> On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu>  
> wrote:
> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>
> Add :register t and :recover t to the open-store keyword list.
>
> You can also try downloading from the elephant-1.0 repo but using:
>
> darcs get --tag=ELEPHANT-1-0-A2 http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>
> Ian
>
>
>
>
> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
> >
> > _______________________________________________
> > 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
>
>




From yarek.kowalik at gmail.com  Wed Mar 11 18:42:27 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Wed, 11 Mar 2009 11:42:27 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <BB4CE71B-360F-424D-A43F-BCBCE0DD7EEA@media.mit.edu>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
	<ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
	<ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>
	<BB4CE71B-360F-424D-A43F-BCBCE0DD7EEA@media.mit.edu>
Message-ID: <ecb948b30903111142h7140d5abv36a7708543ededfd@mail.gmail.com>

- I did a fresh pull from darcs:

  darcs get http://www.common-lisp.net/project/elephant/darcs/elephant-1.0

- I rebuilt elephant, and weblocks/elephant

- I set up my weblocks store with recover and register flags both set to T:

(defstore *elephant-store* :elephant
  :spec `(:BDB ,(namestring (merge-pathnames (make-pathname :directory
'(:relative "data/store"))
                         (asdf-system-directory :fashion-origami)))
                :register t :recover t))

- Run db_recovery in the data store directory

- I started the two processes (one serving port 80 the other 443).

- Went to 443 first.  All is well.

- Went to 80 next.  Webapp application dies (trace below).

*Note:* The trace does not look much different from before.

*Note2:* SLIME died when compiling elephant - got stuck on

gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/include/
-shared -march=x86-64 -fPIC -Wall -g -O2 -g
/home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c -o
/home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.so -lm

I recompiled from command line and got these warnings:

/home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In function
?lisp_compare2?:
/home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1053:
warning: unused variable ?i?
/home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In function
?lisp_compare_key2?:
/home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1147:
warning: unused variable ?i?



Not sure how to proceed.  In order to ensure that I'm doing the right steps,
can you please confirm:

1. Are my weblocks store settings correct?
2. Did I get the right repository for darcs
3. is manual compilation OK for libberkeley-db.so?

Yarek

Here is what I get as debug trace:

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-2" RUNNING {1003705211}>)

Backtrace:
  0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)
{100296C8F9}>)
  1: (SWANK::DEBUG-IN-EMACS #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
  2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003089A39}>)
  3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10036CB5E1}>
#<CLOSURE (LAMBDA #) {1003089A59}>)
  4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10036CB5E1}>
#<CLOSURE (LAMBDA #) {1003089A39}>)
  5: (SWANK:INVOKE-SLIME-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
  6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10030899F9}>)
  7: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
  8: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
  9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))
#<unavailable argument> #<unavailable argument> #<ELEPHANT:BDB-DB-ERROR
{1003081261}>)
 10: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
 11: (ERROR #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
 12: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
 13: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
 14: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[: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::EXECUTE-TRANSACTION
(DB-BDB::BDB-STORE-CONTROLLER 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>
 17: (ELEPHANT::MAP-BTREE-VALUES #<unavailable lambda list>)
      [No Locals]
 18: (ELEPHANT::GET-DB-SCHEMAS #<unavailable lambda list>)
      [No Locals]
 19: (ELEPHANT:MAP-CLASS #<unavailable argument> #<unavailable
argument>)[:EXTERNAL]
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
 20: ((SB-PCL::FAST-METHOD WEBLOCKS:COUNT-PERSISTENT-OBJECTS
(WEBLOCKS-ELEPHANT:ELEPHANT-STORE T)) ..)[:EXTERNAL]
      Locals:
        SB-DEBUG::ARG-0 = 4
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-3 = #<WEBLOCKS-ELEPHANT:ELEPHANT-STORE {1002D92011}>
        SB-DEBUG::ARG-4 = FASHION-ORIGAMI::PRODUCT-SET


On Wed, Mar 11, 2009 at 10:38 AM, Ian Eslick <eslick at media.mit.edu> wrote:

> BDB docs state that :register t :recover t solve the multi-process recover
> problem.  If you have already registered a process, it will inhibit recovery
> when a second process connects.
>
> I have another user with a deserialization error problem.  Try updating to
> the latest elephant-1.0 and you should see an updated deserialization-error
> report in the backtrace that tells you more about why there was an error.
>
> Ian
>
>
> On Mar 11, 2009, at 1:28 PM, Yarek Kowalik wrote:
>
>  Ok so that did not work.
>>
>> I remember that last time I had to remove :recover t from OPEN-STORE
>> method in weblocks/src/store/elephant/elephant.lisp since that was the
>> source of problems with opening a store with two processes.  I think it
>> forces the recovery mode at connection startup.
>>
>> I wonder if I should try :recover nil :register t -- doing that now.
>>
>> Yarek
>>
>> On Wed, Mar 11, 2009 at 10:06 AM, Yarek Kowalik <yarek.kowalik at gmail.com>
>> wrote:
>> Info:
>>
>> - BDB 4.7.
>> - Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is using) and
>> 64 bit (AMD X2 64) versions.
>> - got the ELEPHANT-1-0-A2 via darcs
>>
>> I'm trying out the :register t and :recover t options now.
>>
>> Yarek
>>
>>
>> On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu> wrote:
>> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>>
>> Add :register t and :recover t to the open-store keyword list.
>>
>> You can also try downloading from the elephant-1.0 repo but using:
>>
>> darcs get --tag=ELEPHANT-1-0-A2
>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>
>> Ian
>>
>>
>>
>>
>> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
>> >
>> > _______________________________________________
>> > 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/20090311/d45b5f1a/attachment.html>

From yarek.kowalik at gmail.com  Wed Mar 11 19:38:43 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Wed, 11 Mar 2009 12:38:43 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903111142h7140d5abv36a7708543ededfd@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
	<ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
	<ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>
	<BB4CE71B-360F-424D-A43F-BCBCE0DD7EEA@media.mit.edu>
	<ecb948b30903111142h7140d5abv36a7708543ededfd@mail.gmail.com>
Message-ID: <ecb948b30903111238s68b362b6qafc079e8a793a815@mail.gmail.com>

More info about my configuration:

#+(and (or sbcl allegro openmcl lispworks) (not (or mswindows windows)) (not
(or macosx darwin)))
((:compiler             . :gcc)
 (:berkeley-db-version         . "4.7")
 (:berkeley-db-include-dir    . "/usr/local/BerkeleyDB.4.7/include/")
 (:berkeley-db-lib-dir         . "/usr/local/BerkeleyDB.4.7/lib/")
 (:berkeley-db-lib         . "/usr/local/BerkeleyDB.4.7/lib/libdb-4.7.so")
 (:berkeley-db-deadlock     . "/usr/local/BerkeleyDB.4.7/bin/db_deadlock")
 (:berkeley-db-cachesize     . 20971520)
 (:berkeley-db-max-locks     . 2000)
 (:berkeley-db-max-objects     . 2000)
 (:berkeley-db-map-degree2     . t)
 (:clsql-lib-paths         . nil)
 (:prebuilt-libraries         . nil))



On Wed, Mar 11, 2009 at 11:42 AM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:

> - I did a fresh pull from darcs:
>
>   darcs get http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>
> - I rebuilt elephant, and weblocks/elephant
>
> - I set up my weblocks store with recover and register flags both set to T:
>
> (defstore *elephant-store* :elephant
>   :spec `(:BDB ,(namestring (merge-pathnames (make-pathname :directory
> '(:relative "data/store"))
>                          (asdf-system-directory :fashion-origami)))
>                 :register t :recover t))
>
> - Run db_recovery in the data store directory
>
> - I started the two processes (one serving port 80 the other 443).
>
> - Went to 443 first.  All is well.
>
> - Went to 80 next.  Webapp application dies (trace below).
>
> *Note:* The trace does not look much different from before.
>
> *Note2:* SLIME died when compiling elephant - got stuck on
>
> gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/include/
> -shared -march=x86-64 -fPIC -Wall -g -O2 -g
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c -o
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.so -lm
>
> I recompiled from command line and got these warnings:
>
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
> function ?lisp_compare2?:
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1053:
> warning: unused variable ?i?
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
> function ?lisp_compare_key2?:
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1147:
> warning: unused variable ?i?
>
>
>
> Not sure how to proceed.  In order to ensure that I'm doing the right
> steps, can you please confirm:
>
> 1. Are my weblocks store settings correct?
> 2. Did I get the right repository for darcs
> 3. is manual compilation OK for libberkeley-db.so?
>
> Yarek
>
> Here is what I get as debug trace:
>
> 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-2" RUNNING {1003705211}>)
>
> Backtrace:
>   0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)
> {100296C8F9}>)
>   1: (SWANK::DEBUG-IN-EMACS #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>   2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003089A39}>)
>   3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10036CB5E1}>
> #<CLOSURE (LAMBDA #) {1003089A59}>)
>   4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10036CB5E1}>
> #<CLOSURE (LAMBDA #) {1003089A39}>)
>   5: (SWANK:INVOKE-SLIME-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>   6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10030899F9}>)
>   7: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>   8: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>   9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))
> #<unavailable argument> #<unavailable argument> #<ELEPHANT:BDB-DB-ERROR
> {1003081261}>)
>  10: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>  11: (ERROR #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>  12: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>  13: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>  14: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[: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::EXECUTE-TRANSACTION
> (DB-BDB::BDB-STORE-CONTROLLER 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>
>  17: (ELEPHANT::MAP-BTREE-VALUES #<unavailable lambda list>)
>       [No Locals]
>  18: (ELEPHANT::GET-DB-SCHEMAS #<unavailable lambda list>)
>       [No Locals]
>  19: (ELEPHANT:MAP-CLASS #<unavailable argument> #<unavailable
> argument>)[:EXTERNAL]
>       Locals:
>         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>  20: ((SB-PCL::FAST-METHOD WEBLOCKS:COUNT-PERSISTENT-OBJECTS
> (WEBLOCKS-ELEPHANT:ELEPHANT-STORE T)) ..)[:EXTERNAL]
>       Locals:
>         SB-DEBUG::ARG-0 = 4
>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-3 = #<WEBLOCKS-ELEPHANT:ELEPHANT-STORE {1002D92011}>
>         SB-DEBUG::ARG-4 = FASHION-ORIGAMI::PRODUCT-SET
>
>
>
> On Wed, Mar 11, 2009 at 10:38 AM, Ian Eslick <eslick at media.mit.edu> wrote:
>
>> BDB docs state that :register t :recover t solve the multi-process recover
>> problem.  If you have already registered a process, it will inhibit recovery
>> when a second process connects.
>>
>> I have another user with a deserialization error problem.  Try updating to
>> the latest elephant-1.0 and you should see an updated deserialization-error
>> report in the backtrace that tells you more about why there was an error.
>>
>> Ian
>>
>>
>> On Mar 11, 2009, at 1:28 PM, Yarek Kowalik wrote:
>>
>>  Ok so that did not work.
>>>
>>> I remember that last time I had to remove :recover t from OPEN-STORE
>>> method in weblocks/src/store/elephant/elephant.lisp since that was the
>>> source of problems with opening a store with two processes.  I think it
>>> forces the recovery mode at connection startup.
>>>
>>> I wonder if I should try :recover nil :register t -- doing that now.
>>>
>>> Yarek
>>>
>>> On Wed, Mar 11, 2009 at 10:06 AM, Yarek Kowalik <yarek.kowalik at gmail.com>
>>> wrote:
>>> Info:
>>>
>>> - BDB 4.7.
>>> - Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is using) and
>>> 64 bit (AMD X2 64) versions.
>>> - got the ELEPHANT-1-0-A2 via darcs
>>>
>>> I'm trying out the :register t and :recover t options now.
>>>
>>> Yarek
>>>
>>>
>>> On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu>
>>> wrote:
>>> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>>>
>>> Add :register t and :recover t to the open-store keyword list.
>>>
>>> You can also try downloading from the elephant-1.0 repo but using:
>>>
>>> darcs get --tag=ELEPHANT-1-0-A2
>>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
>>> >
>>> > _______________________________________________
>>> > 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/20090311/d92effaf/attachment.html>

From yarek.kowalik at gmail.com  Wed Mar 11 19:48:31 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Wed, 11 Mar 2009 12:48:31 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903111142h7140d5abv36a7708543ededfd@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
	<ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
	<ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>
	<BB4CE71B-360F-424D-A43F-BCBCE0DD7EEA@media.mit.edu>
	<ecb948b30903111142h7140d5abv36a7708543ededfd@mail.gmail.com>
Message-ID: <ecb948b30903111248yc809066x9aec264c070198c9@mail.gmail.com>

Hi Ian,

I did some digging. Reading in the DB docs:

*DB_REGISTER*

   - Check to see if recovery needs to be performed before opening the
   database environment. (For this check to be accurate, all processes using
   the environment must specify DB_REGISTER when opening the environment.) If
   recovery needs to be performed for any reason (including the initial use of
   the DB_REGISTER flag), and DB_RECOVER is also specified, recovery will be
   performed and the open will proceed normally. If recovery needs to be
   performed and DB_RECOVER is not specified,
DB_RUNRECOVERY<http://www.oracle.com/technology/documentation/berkeley-db/db/ref/program/errorret.html#DB_RUNRECOVERY>will
be returned. If recovery does not need to be performed, the DB_RECOVER
   flag will be ignored. See Architecting Transactional Data Store
   applications<http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/app.html>for
more information.

I'm getting the DB_RUNRECOVERY error, which is strange since the settings
are :recover T and :register T.  So, either I'm not setting the parameters
correctly, elephant is not setting the corresponding DB_* flags correctly,
or BerkleyDB is somehow broken.

The last one is less likely since my Jan build of elephant worked, and you
indicated that the :recovery was being set to T by default then.

The first one is potentially true, but digging in whith the SLIME inspector
I can see that the controller's value of SPEC slot set as follows:

#<CONS {1007C4BCF7}>
--------------------
A proper list:
0: :BDB
1: "/home/yarek/lisp/projects/fashion-origami/data/store/"
2: :REGISTER
3: T
4: :RECOVER
5: T

I'm digging into elephant code now to see if I can see the DB_* flags being
set.  Let me know if you have any more insight.

Thanks,

Yarek




On Wed, Mar 11, 2009 at 11:42 AM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:

> - I did a fresh pull from darcs:
>
>   darcs get http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>
> - I rebuilt elephant, and weblocks/elephant
>
> - I set up my weblocks store with recover and register flags both set to T:
>
> (defstore *elephant-store* :elephant
>   :spec `(:BDB ,(namestring (merge-pathnames (make-pathname :directory
> '(:relative "data/store"))
>                          (asdf-system-directory :fashion-origami)))
>                 :register t :recover t))
>
> - Run db_recovery in the data store directory
>
> - I started the two processes (one serving port 80 the other 443).
>
> - Went to 443 first.  All is well.
>
> - Went to 80 next.  Webapp application dies (trace below).
>
> *Note:* The trace does not look much different from before.
>
> *Note2:* SLIME died when compiling elephant - got stuck on
>
> gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/include/
> -shared -march=x86-64 -fPIC -Wall -g -O2 -g
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c -o
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.so -lm
>
> I recompiled from command line and got these warnings:
>
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
> function ?lisp_compare2?:
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1053:
> warning: unused variable ?i?
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
> function ?lisp_compare_key2?:
> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1147:
> warning: unused variable ?i?
>
>
>
> Not sure how to proceed.  In order to ensure that I'm doing the right
> steps, can you please confirm:
>
> 1. Are my weblocks store settings correct?
> 2. Did I get the right repository for darcs
> 3. is manual compilation OK for libberkeley-db.so?
>
> Yarek
>
> Here is what I get as debug trace:
>
> 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-2" RUNNING {1003705211}>)
>
> Backtrace:
>   0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)
> {100296C8F9}>)
>   1: (SWANK::DEBUG-IN-EMACS #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>   2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003089A39}>)
>   3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10036CB5E1}>
> #<CLOSURE (LAMBDA #) {1003089A59}>)
>   4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10036CB5E1}>
> #<CLOSURE (LAMBDA #) {1003089A39}>)
>   5: (SWANK:INVOKE-SLIME-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>   6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10030899F9}>)
>   7: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>   8: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>   9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))
> #<unavailable argument> #<unavailable argument> #<ELEPHANT:BDB-DB-ERROR
> {1003081261}>)
>  10: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>  11: (ERROR #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>  12: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>  13: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>  14: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[: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::EXECUTE-TRANSACTION
> (DB-BDB::BDB-STORE-CONTROLLER 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>
>  17: (ELEPHANT::MAP-BTREE-VALUES #<unavailable lambda list>)
>       [No Locals]
>  18: (ELEPHANT::GET-DB-SCHEMAS #<unavailable lambda list>)
>       [No Locals]
>  19: (ELEPHANT:MAP-CLASS #<unavailable argument> #<unavailable
> argument>)[:EXTERNAL]
>       Locals:
>         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>  20: ((SB-PCL::FAST-METHOD WEBLOCKS:COUNT-PERSISTENT-OBJECTS
> (WEBLOCKS-ELEPHANT:ELEPHANT-STORE T)) ..)[:EXTERNAL]
>       Locals:
>         SB-DEBUG::ARG-0 = 4
>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>         SB-DEBUG::ARG-3 = #<WEBLOCKS-ELEPHANT:ELEPHANT-STORE {1002D92011}>
>         SB-DEBUG::ARG-4 = FASHION-ORIGAMI::PRODUCT-SET
>
>
>
> On Wed, Mar 11, 2009 at 10:38 AM, Ian Eslick <eslick at media.mit.edu> wrote:
>
>> BDB docs state that :register t :recover t solve the multi-process recover
>> problem.  If you have already registered a process, it will inhibit recovery
>> when a second process connects.
>>
>> I have another user with a deserialization error problem.  Try updating to
>> the latest elephant-1.0 and you should see an updated deserialization-error
>> report in the backtrace that tells you more about why there was an error.
>>
>> Ian
>>
>>
>> On Mar 11, 2009, at 1:28 PM, Yarek Kowalik wrote:
>>
>>  Ok so that did not work.
>>>
>>> I remember that last time I had to remove :recover t from OPEN-STORE
>>> method in weblocks/src/store/elephant/elephant.lisp since that was the
>>> source of problems with opening a store with two processes.  I think it
>>> forces the recovery mode at connection startup.
>>>
>>> I wonder if I should try :recover nil :register t -- doing that now.
>>>
>>> Yarek
>>>
>>> On Wed, Mar 11, 2009 at 10:06 AM, Yarek Kowalik <yarek.kowalik at gmail.com>
>>> wrote:
>>> Info:
>>>
>>> - BDB 4.7.
>>> - Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is using) and
>>> 64 bit (AMD X2 64) versions.
>>> - got the ELEPHANT-1-0-A2 via darcs
>>>
>>> I'm trying out the :register t and :recover t options now.
>>>
>>> Yarek
>>>
>>>
>>> On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu>
>>> wrote:
>>> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>>>
>>> Add :register t and :recover t to the open-store keyword list.
>>>
>>> You can also try downloading from the elephant-1.0 repo but using:
>>>
>>> darcs get --tag=ELEPHANT-1-0-A2
>>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
>>> >
>>> > _______________________________________________
>>> > 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/20090311/937386d9/attachment.html>

From yarek.kowalik at gmail.com  Wed Mar 11 22:40:44 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Wed, 11 Mar 2009 15:40:44 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903111248yc809066x9aec264c070198c9@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
	<ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
	<ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>
	<BB4CE71B-360F-424D-A43F-BCBCE0DD7EEA@media.mit.edu>
	<ecb948b30903111142h7140d5abv36a7708543ededfd@mail.gmail.com>
	<ecb948b30903111248yc809066x9aec264c070198c9@mail.gmail.com>
Message-ID: <ecb948b30903111540w1d5916a4ve32165462a6ee039@mail.gmail.com>

Method open-controller (in bdb-controller.lisp) is not getting the register
parameter I'm specifying.  I'm investigating why.

Yarek

On Wed, Mar 11, 2009 at 12:48 PM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:

> Hi Ian,
>
> I did some digging. Reading in the DB docs:
>
> *DB_REGISTER*
>
>    - Check to see if recovery needs to be performed before opening the
>    database environment. (For this check to be accurate, all processes using
>    the environment must specify DB_REGISTER when opening the environment.) If
>    recovery needs to be performed for any reason (including the initial use of
>    the DB_REGISTER flag), and DB_RECOVER is also specified, recovery will be
>    performed and the open will proceed normally. If recovery needs to be
>    performed and DB_RECOVER is not specified, DB_RUNRECOVERY<http://www.oracle.com/technology/documentation/berkeley-db/db/ref/program/errorret.html#DB_RUNRECOVERY>will be returned. If recovery does not need to be performed, the DB_RECOVER
>    flag will be ignored. See Architecting Transactional Data Store
>    applications<http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/app.html>for more information.
>
> I'm getting the DB_RUNRECOVERY error, which is strange since the settings
> are :recover T and :register T.  So, either I'm not setting the parameters
> correctly, elephant is not setting the corresponding DB_* flags correctly,
> or BerkleyDB is somehow broken.
>
> The last one is less likely since my Jan build of elephant worked, and you
> indicated that the :recovery was being set to T by default then.
>
> The first one is potentially true, but digging in whith the SLIME inspector
> I can see that the controller's value of SPEC slot set as follows:
>
> #<CONS {1007C4BCF7}>
> --------------------
> A proper list:
> 0: :BDB
> 1: "/home/yarek/lisp/projects/fashion-origami/data/store/"
> 2: :REGISTER
> 3: T
> 4: :RECOVER
> 5: T
>
> I'm digging into elephant code now to see if I can see the DB_* flags being
> set.  Let me know if you have any more insight.
>
> Thanks,
>
> Yarek
>
>
>
>
>
> On Wed, Mar 11, 2009 at 11:42 AM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:
>
>> - I did a fresh pull from darcs:
>>
>>   darcs get
>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>
>> - I rebuilt elephant, and weblocks/elephant
>>
>> - I set up my weblocks store with recover and register flags both set to
>> T:
>>
>> (defstore *elephant-store* :elephant
>>   :spec `(:BDB ,(namestring (merge-pathnames (make-pathname :directory
>> '(:relative "data/store"))
>>                          (asdf-system-directory :fashion-origami)))
>>                 :register t :recover t))
>>
>> - Run db_recovery in the data store directory
>>
>> - I started the two processes (one serving port 80 the other 443).
>>
>> - Went to 443 first.  All is well.
>>
>> - Went to 80 next.  Webapp application dies (trace below).
>>
>> *Note:* The trace does not look much different from before.
>>
>> *Note2:* SLIME died when compiling elephant - got stuck on
>>
>> gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/include/
>> -shared -march=x86-64 -fPIC -Wall -g -O2 -g
>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c -o
>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.so -lm
>>
>> I recompiled from command line and got these warnings:
>>
>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
>> function ?lisp_compare2?:
>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1053:
>> warning: unused variable ?i?
>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
>> function ?lisp_compare_key2?:
>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1147:
>> warning: unused variable ?i?
>>
>>
>>
>> Not sure how to proceed.  In order to ensure that I'm doing the right
>> steps, can you please confirm:
>>
>> 1. Are my weblocks store settings correct?
>> 2. Did I get the right repository for darcs
>> 3. is manual compilation OK for libberkeley-db.so?
>>
>> Yarek
>>
>> Here is what I get as debug trace:
>>
>> 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-2" RUNNING {1003705211}>)
>>
>> Backtrace:
>>   0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)
>> {100296C8F9}>)
>>   1: (SWANK::DEBUG-IN-EMACS #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>   2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
>> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003089A39}>)
>>   3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10036CB5E1}>
>> #<CLOSURE (LAMBDA #) {1003089A59}>)
>>   4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10036CB5E1}>
>> #<CLOSURE (LAMBDA #) {1003089A39}>)
>>   5: (SWANK:INVOKE-SLIME-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>   6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
>> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10030899F9}>)
>>   7: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>   8: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>   9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))
>> #<unavailable argument> #<unavailable argument> #<ELEPHANT:BDB-DB-ERROR
>> {1003081261}>)
>>  10: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>  11: (ERROR #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>  12: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>  13: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>  14: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[: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::EXECUTE-TRANSACTION
>> (DB-BDB::BDB-STORE-CONTROLLER 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>
>>  17: (ELEPHANT::MAP-BTREE-VALUES #<unavailable lambda list>)
>>       [No Locals]
>>  18: (ELEPHANT::GET-DB-SCHEMAS #<unavailable lambda list>)
>>       [No Locals]
>>  19: (ELEPHANT:MAP-CLASS #<unavailable argument> #<unavailable
>> argument>)[:EXTERNAL]
>>       Locals:
>>         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>>  20: ((SB-PCL::FAST-METHOD WEBLOCKS:COUNT-PERSISTENT-OBJECTS
>> (WEBLOCKS-ELEPHANT:ELEPHANT-STORE T)) ..)[:EXTERNAL]
>>       Locals:
>>         SB-DEBUG::ARG-0 = 4
>>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>>         SB-DEBUG::ARG-3 = #<WEBLOCKS-ELEPHANT:ELEPHANT-STORE {1002D92011}>
>>         SB-DEBUG::ARG-4 = FASHION-ORIGAMI::PRODUCT-SET
>>
>>
>>
>> On Wed, Mar 11, 2009 at 10:38 AM, Ian Eslick <eslick at media.mit.edu>wrote:
>>
>>> BDB docs state that :register t :recover t solve the multi-process
>>> recover problem.  If you have already registered a process, it will inhibit
>>> recovery when a second process connects.
>>>
>>> I have another user with a deserialization error problem.  Try updating
>>> to the latest elephant-1.0 and you should see an updated
>>> deserialization-error report in the backtrace that tells you more about why
>>> there was an error.
>>>
>>> Ian
>>>
>>>
>>> On Mar 11, 2009, at 1:28 PM, Yarek Kowalik wrote:
>>>
>>>  Ok so that did not work.
>>>>
>>>> I remember that last time I had to remove :recover t from OPEN-STORE
>>>> method in weblocks/src/store/elephant/elephant.lisp since that was the
>>>> source of problems with opening a store with two processes.  I think it
>>>> forces the recovery mode at connection startup.
>>>>
>>>> I wonder if I should try :recover nil :register t -- doing that now.
>>>>
>>>> Yarek
>>>>
>>>> On Wed, Mar 11, 2009 at 10:06 AM, Yarek Kowalik <
>>>> yarek.kowalik at gmail.com> wrote:
>>>> Info:
>>>>
>>>> - BDB 4.7.
>>>> - Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is using)
>>>> and 64 bit (AMD X2 64) versions.
>>>> - got the ELEPHANT-1-0-A2 via darcs
>>>>
>>>> I'm trying out the :register t and :recover t options now.
>>>>
>>>> Yarek
>>>>
>>>>
>>>> On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu>
>>>> wrote:
>>>> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>>>>
>>>> Add :register t and :recover t to the open-store keyword list.
>>>>
>>>> You can also try downloading from the elephant-1.0 repo but using:
>>>>
>>>> darcs get --tag=ELEPHANT-1-0-A2
>>>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>>>
>>>> Ian
>>>>
>>>>
>>>>
>>>>
>>>> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
>>>> >
>>>> > _______________________________________________
>>>> > 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/20090311/d1787214/attachment.html>

From yarek.kowalik at gmail.com  Wed Mar 11 22:59:04 2009
From: yarek.kowalik at gmail.com (Yarek Kowalik)
Date: Wed, 11 Mar 2009 15:59:04 -0700
Subject: [elephant-devel] BDB Run recovery errors seen after switching
	to ELEPHANT-1-0-A2
In-Reply-To: <ecb948b30903111540w1d5916a4ve32165462a6ee039@mail.gmail.com>
References: <ecb948b30903101431u3bb2e1e8p5ef889bbee4fa854@mail.gmail.com>
	<207FDA0E-6FC0-4F88-944C-512717C1D3AD@media.mit.edu>
	<ecb948b30903101557r58a56a69sbd0f080608f093e3@mail.gmail.com>
	<6A6E86F0-F6E3-4E59-BA04-9FE750000CD8@media.mit.edu>
	<ecb948b30903111006i3b533d7o9ce3c7865ca848f6@mail.gmail.com>
	<ecb948b30903111028s497c9cc5i7b0b704a7cf18e78@mail.gmail.com>
	<BB4CE71B-360F-424D-A43F-BCBCE0DD7EEA@media.mit.edu>
	<ecb948b30903111142h7140d5abv36a7708543ededfd@mail.gmail.com>
	<ecb948b30903111248yc809066x9aec264c070198c9@mail.gmail.com>
	<ecb948b30903111540w1d5916a4ve32165462a6ee039@mail.gmail.com>
Message-ID: <ecb948b30903111559h34b7bfa1s446a28c421c72555@mail.gmail.com>

Solved: problem is with weblocs elephant store.  I'm supplying the patch
there.

Thanks for the advice and pointers.  It was much easier to figure it out
once I knew what parameters were required - once I traced the parameter path
it was pretty straightforward.

Yarek

On Wed, Mar 11, 2009 at 3:40 PM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:

> Method open-controller (in bdb-controller.lisp) is not getting the register
> parameter I'm specifying.  I'm investigating why.
>
> Yarek
>
>
> On Wed, Mar 11, 2009 at 12:48 PM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:
>
>> Hi Ian,
>>
>> I did some digging. Reading in the DB docs:
>>
>> *DB_REGISTER*
>>
>>    - Check to see if recovery needs to be performed before opening the
>>    database environment. (For this check to be accurate, all processes using
>>    the environment must specify DB_REGISTER when opening the environment.) If
>>    recovery needs to be performed for any reason (including the initial use of
>>    the DB_REGISTER flag), and DB_RECOVER is also specified, recovery will be
>>    performed and the open will proceed normally. If recovery needs to be
>>    performed and DB_RECOVER is not specified, DB_RUNRECOVERY<http://www.oracle.com/technology/documentation/berkeley-db/db/ref/program/errorret.html#DB_RUNRECOVERY>will be returned. If recovery does not need to be performed, the DB_RECOVER
>>    flag will be ignored. See Architecting Transactional Data Store
>>    applications<http://www.oracle.com/technology/documentation/berkeley-db/db/ref/transapp/app.html>for more information.
>>
>> I'm getting the DB_RUNRECOVERY error, which is strange since the settings
>> are :recover T and :register T.  So, either I'm not setting the parameters
>> correctly, elephant is not setting the corresponding DB_* flags correctly,
>> or BerkleyDB is somehow broken.
>>
>> The last one is less likely since my Jan build of elephant worked, and you
>> indicated that the :recovery was being set to T by default then.
>>
>> The first one is potentially true, but digging in whith the SLIME
>> inspector I can see that the controller's value of SPEC slot set as follows:
>>
>> #<CONS {1007C4BCF7}>
>> --------------------
>> A proper list:
>> 0: :BDB
>> 1: "/home/yarek/lisp/projects/fashion-origami/data/store/"
>> 2: :REGISTER
>> 3: T
>> 4: :RECOVER
>> 5: T
>>
>> I'm digging into elephant code now to see if I can see the DB_* flags
>> being set.  Let me know if you have any more insight.
>>
>> Thanks,
>>
>> Yarek
>>
>>
>>
>>
>>
>> On Wed, Mar 11, 2009 at 11:42 AM, Yarek Kowalik <yarek.kowalik at gmail.com>wrote:
>>
>>> - I did a fresh pull from darcs:
>>>
>>>   darcs get
>>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>>
>>> - I rebuilt elephant, and weblocks/elephant
>>>
>>> - I set up my weblocks store with recover and register flags both set to
>>> T:
>>>
>>> (defstore *elephant-store* :elephant
>>>   :spec `(:BDB ,(namestring (merge-pathnames (make-pathname :directory
>>> '(:relative "data/store"))
>>>                          (asdf-system-directory :fashion-origami)))
>>>                 :register t :recover t))
>>>
>>> - Run db_recovery in the data store directory
>>>
>>> - I started the two processes (one serving port 80 the other 443).
>>>
>>> - Went to 443 first.  All is well.
>>>
>>> - Went to 80 next.  Webapp application dies (trace below).
>>>
>>> *Note:* The trace does not look much different from before.
>>>
>>> *Note2:* SLIME died when compiling elephant - got stuck on
>>>
>>> gcc -L/usr/local/BerkeleyDB.4.7/lib/ -I/usr/local/BerkeleyDB.4.7/include/
>>> -shared -march=x86-64 -fPIC -Wall -g -O2 -g
>>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c -o
>>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.so -lm
>>>
>>> I recompiled from command line and got these warnings:
>>>
>>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
>>> function ?lisp_compare2?:
>>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1053:
>>> warning: unused variable ?i?
>>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c: In
>>> function ?lisp_compare_key2?:
>>> /home/yarek/.sbcl/site/elephant-1.0/src/db-bdb/libberkeley-db.c:1147:
>>> warning: unused variable ?i?
>>>
>>>
>>>
>>> Not sure how to proceed.  In order to ensure that I'm doing the right
>>> steps, can you please confirm:
>>>
>>> 1. Are my weblocks store settings correct?
>>> 2. Did I get the right repository for darcs
>>> 3. is manual compilation OK for libberkeley-db.so?
>>>
>>> Yarek
>>>
>>> Here is what I get as debug trace:
>>>
>>> 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-2" RUNNING {1003705211}>)
>>>
>>> Backtrace:
>>>   0: ((LAMBDA (SWANK-BACKEND::DEBUGGER-LOOP-FN)) #<FUNCTION (LAMBDA #)
>>> {100296C8F9}>)
>>>   1: (SWANK::DEBUG-IN-EMACS #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>>   2: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
>>> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {1003089A39}>)
>>>   3: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {10036CB5E1}>
>>> #<CLOSURE (LAMBDA #) {1003089A59}>)
>>>   4: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {10036CB5E1}>
>>> #<CLOSURE (LAMBDA #) {1003089A39}>)
>>>   5: (SWANK:INVOKE-SLIME-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>>   6: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
>>> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {10030899F9}>)
>>>   7: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>>   8: (INVOKE-DEBUGGER #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>>   9: ((SB-PCL::FAST-METHOD HUNCHENTOOT:MAYBE-INVOKE-DEBUGGER (T))
>>> #<unavailable argument> #<unavailable argument> #<ELEPHANT:BDB-DB-ERROR
>>> {1003081261}>)
>>>  10: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>>  11: (ERROR #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>>  12: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)
>>>  13: ((FLET #:LAMBDA43) #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[:EXTERNAL]
>>>  14: (SIGNAL #<ELEPHANT:BDB-DB-ERROR {1003081261}>)[: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::EXECUTE-TRANSACTION
>>> (DB-BDB::BDB-STORE-CONTROLLER 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>
>>>  17: (ELEPHANT::MAP-BTREE-VALUES #<unavailable lambda list>)
>>>       [No Locals]
>>>  18: (ELEPHANT::GET-DB-SCHEMAS #<unavailable lambda list>)
>>>       [No Locals]
>>>  19: (ELEPHANT:MAP-CLASS #<unavailable argument> #<unavailable
>>> argument>)[:EXTERNAL]
>>>       Locals:
>>>         SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>>>  20: ((SB-PCL::FAST-METHOD WEBLOCKS:COUNT-PERSISTENT-OBJECTS
>>> (WEBLOCKS-ELEPHANT:ELEPHANT-STORE T)) ..)[:EXTERNAL]
>>>       Locals:
>>>         SB-DEBUG::ARG-0 = 4
>>>         SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>>         SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>>>         SB-DEBUG::ARG-3 = #<WEBLOCKS-ELEPHANT:ELEPHANT-STORE
>>> {1002D92011}>
>>>         SB-DEBUG::ARG-4 = FASHION-ORIGAMI::PRODUCT-SET
>>>
>>>
>>>
>>> On Wed, Mar 11, 2009 at 10:38 AM, Ian Eslick <eslick at media.mit.edu>wrote:
>>>
>>>> BDB docs state that :register t :recover t solve the multi-process
>>>> recover problem.  If you have already registered a process, it will inhibit
>>>> recovery when a second process connects.
>>>>
>>>> I have another user with a deserialization error problem.  Try updating
>>>> to the latest elephant-1.0 and you should see an updated
>>>> deserialization-error report in the backtrace that tells you more about why
>>>> there was an error.
>>>>
>>>> Ian
>>>>
>>>>
>>>> On Mar 11, 2009, at 1:28 PM, Yarek Kowalik wrote:
>>>>
>>>>  Ok so that did not work.
>>>>>
>>>>> I remember that last time I had to remove :recover t from OPEN-STORE
>>>>> method in weblocks/src/store/elephant/elephant.lisp since that was the
>>>>> source of problems with opening a store with two processes.  I think it
>>>>> forces the recovery mode at connection startup.
>>>>>
>>>>> I wonder if I should try :recover nil :register t -- doing that now.
>>>>>
>>>>> Yarek
>>>>>
>>>>> On Wed, Mar 11, 2009 at 10:06 AM, Yarek Kowalik <
>>>>> yarek.kowalik at gmail.com> wrote:
>>>>> Info:
>>>>>
>>>>> - BDB 4.7.
>>>>> - Ubuntu 8.04 on both 32 bit (Intel and whatever Amazon EC2 is using)
>>>>> and 64 bit (AMD X2 64) versions.
>>>>> - got the ELEPHANT-1-0-A2 via darcs
>>>>>
>>>>> I'm trying out the :register t and :recover t options now.
>>>>>
>>>>> Yarek
>>>>>
>>>>>
>>>>> On Tue, Mar 10, 2009 at 4:20 PM, Ian Eslick <eslick at media.mit.edu>
>>>>> wrote:
>>>>> You're using BDB 4.7, right?  What machine, os, word-width, etc?
>>>>>
>>>>> Add :register t and :recover t to the open-store keyword list.
>>>>>
>>>>> You can also try downloading from the elephant-1.0 repo but using:
>>>>>
>>>>> darcs get --tag=ELEPHANT-1-0-A2
>>>>> http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>>>>
>>>>> Ian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mar 10, 2009, at 6:57 PM, Yarek Kowalik 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
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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/20090311/5585f15e/attachment.html>

From eslick at media.mit.edu  Fri Mar 13 01:03:15 2009
From: eslick at media.mit.edu (Ian Eslick)
Date: Thu, 12 Mar 2009 21:03:15 -0400
Subject: [elephant-devel] elephant installation on sbcl 1.0.26.1
In-Reply-To: <544191d90903121347l15c07e05hdd26b41853da76a5@mail.gmail.com>
References: <544191d90903120200o6009a203idb8735256cbeaf36@mail.gmail.com>
	<A79C62CF-4ACB-4241-B60F-E16DAF4D52E7@media.mit.edu>
	<544191d90903121347l15c07e05hdd26b41853da76a5@mail.gmail.com>
Message-ID: <FC584293-0BC1-4EE2-85B8-BB5CACC0F267@media.mit.edu>

Great news!  I'm glad it works for you.

The tests are not guaranteed to be idempotent, although we work hard  
to make them so.  Try deleting the test db (the easy way is to use / 
tests/delscript.sh) and re-running; should work great from within  
slime now.

I'll add a ticket for the SLIME subprocess stream problems.

Cheers,
Ian

On Mar 12, 2009, at 4:47 PM, mosi wrote:

> Hi Ian,
>
> it works!
> This is a music to my ears:
> ---
> (do-backend-tests)
> ...
> Single store mode: ignoring.
> Did 500 checks.
>    Pass: 497 (99%)
>    Skip: 0 ( 0%)
>    Fail: 3 ( 0%)
>
> Failure Details:
> --------------------------------
> INDEXING-CHANGE-CLASS []:
>      1 evaluated to 1, which is not = to 2..
> --------------------------------
> --------------------------------
> INDEXING-BASIC []:
>      (LENGTH (GET-INSTANCES-BY-VALUE 'IDX-ONE-F 'SLOT1 N)) evaluated
> to 4, which is not = to 2..
> --------------------------------
> --------------------------------
> INDEXING-BASIC []:
>      (LENGTH (GET-INSTANCES-BY-RANGE 'IDX-ONE-F 'SLOT1 N (+ 1 N)))
> evaluated to 5, which is not = to 3..
> --------------------------------
>
> That was slime environment.
> In the sbcl prompt, all 500 tests passed OK.
> I`m baffled as to why this might be.
>
> Thank you very much,
> let`s try some exciting stuff with elephant.
> Best regards,
> mosi
>
>
> 2009/3/12 Ian Eslick <eslick at media.mit.edu>:
>> A couple of quick points:
>>
>> - The latest elephant requires BDB 4.7
>>
>> - The C compilation step can cause problems when run from
>>   within slime, doing an initial compile from the console typically
>>   fixes this.
>>
>> - Sometimes SBCL complains the compile failed due to package export
>>   or other issues but things are fine.
>>
>> Do you have the trace of activity printed to the lisp repl window?
>> That is more informative than the backtrace.
>>
>> Thanks,
>> Ian
>>
>> On Mar 12, 2009, at 5:00 AM, mosi wrote:
>>
>>> Hi,
>>> i tried the following:
>>> This is SBCL 1.0.26.1 (threading on, unicode on) on debian linux,
>>> compiled from clbuild, run on SLIME 2008-12-23.
>>> I followed the installation instructions from
>>> http://common-lisp.net/project/elephant/doc/
>>>
>>> pulled the latest build:
>>> darcs get http://www.common-lisp.net/project/elephant/darcs/elephant-1.0
>>>
>>> installed all dependencies (lots of them were already installed
>>> previously by asdf-install: and clbuild), the berkeleydb 4.5 in the
>>> default folders, configured the my-config.sexp
>>>
>>> There are some problems during the compilation of elephant:
>>> memutils, serializer, serializer1, serializer2, unicode, etc.  
>>> succeed
>>> to compile, but throw: asdf-compile failed, and recompile does not
>>> help.
>>> -----------
>>> erred while invoking #<COMPILE-OP NIL {B62E909}> on
>>> #<CL-SOURCE-FILE "memutil" {BC60411}>
>>>  [Condition of type ASDF:COMPILE-FAILED]
>>>
>>> Restarts:
>>> 0: [TRY-RECOMPILING] Try recompiling memutil
>>> 1: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {B62E909}> on
>>> #<ASDF:CL-SOURCE-FILE "memutil" {BC60411}>.
>>> 2: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {B62E909}> on
>>> #<ASDF:CL-SOURCE-FILE "memutil" {BC60411}> as having been  
>>> successful.
>>> 3: [RETRY] Retry SLIME REPL evaluation request.
>>> 4: [ABORT] Return to SLIME's top level.
>>> 5: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
>>> RUNNING {B7170D1}>)
>>>
>>> Backtrace:
>>> 0: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
>>> ASDF:CL-SOURCE-FILE)) #<unavailable argument> #<unavailable  
>>> argument>
>>> #<ASDF:COMPILE-OP NIL {B62E909}> #<ASDF:CL-SOURCE-FILE "memutil"
>>> {BC60411}>)
>>>     Locals:
>>>       SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>>       SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>>       SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {B62E909}>
>>>       SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "memutil" {BC60411}>
>>> 1: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
>>> SB-PCL::.ARG1.)) ..)
>>>     Locals:
>>>       SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>>       SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>>       SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {B62E909}>
>>>       SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "memutil" {BC60411}>
>>> 2: ((SB-PCL::FAST-METHOD ASDF:PERFORM ASDF:AROUND (ASDF:COMPILE-OP
>>> ASDF:CL-SOURCE-FILE)) ..)
>>>     Locals:
>>>       SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>>       SB-DEBUG::ARG-1 = #S(SB-PCL::FAST-METHOD-CALL ..)
>>>       SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {B62E909}>
>>>       SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "memutil" {BC60411}>
>>> 3: ((LAMBDA ()))
>>> 4: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
>>> 5: ((FLET #:WITHOUT-INTERRUPTS-BODY-[CALL-WITH-RECURSIVE-LOCK]477))
>>> 6: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK ..)
>>> 7: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {BB53A6D}>)
>>> [:EXTERNAL]
>>> 8: (ASDF:OPERATE ASDF:LOAD-OP :ELEPHANT)[:EXTERNAL]
>>> 9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (ASDF:OPERATE 'ASDF:LOAD-OP
>>> :ELEPHANT) #<NULL-LEXENV>)
>>> 10: (SWANK::EVAL-REGION "(asdf:operate 'asdf:load-op :elephant)\n")
>>> 11: ((LAMBDA ()))
>>> 12: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {AF72AE5}>)
>>> 13: (SWANK::CALL-WITH-RETRY-RESTART "Retry SLIME REPL evaluation
>>> request." #<CLOSURE (LAMBDA #) {AF72A75}>)
>>> 14: (SWANK::CALL-WITH-BUFFER-SYNTAX NIL #<CLOSURE (LAMBDA #)
>>> {AF72A5D}>)
>>> 15: (SWANK::REPL-EVAL "(asdf:operate 'asdf:load-op :elephant)\n")
>>> 16: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SWANK:LISTENER-EVAL  
>>> "(asdf:operate
>>> 'asdf:load-op :elephant)\n") #<NULL-LEXENV>)
>>> 17: (SWANK::EVAL-FOR-EMACS (SWANK:LISTENER-EVAL "(asdf:operate
>>> 'asdf:load-op :elephant)\n") "COMMON-LISP-USER" 13)
>>> 18: (SWANK::PROCESS-REQUESTS NIL)
>>> 19: ((LAMBDA ()))
>>> 20: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN)) #<FUNCTION
>>> SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA #) {B85D7AD}>)
>>> 21: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {B48E811}>
>>> #<CLOSURE (LAMBDA #) {B85D7BD}>)
>>> 22: (SWANK::CALL-WITH-CONNECTION #<SWANK::CONNECTION {B48E811}>
>>> #<CLOSURE (LAMBDA #) {B85D7AD}>)
>>> 23: (SWANK::HANDLE-REQUESTS #<SWANK::CONNECTION {B48E811}> NIL)
>>> ------------
>>> After accepting the compilation as successful, everything looks ok:
>>>
>>> ; caught WARNING:
>>> ;   These variables are undefined:
>>> ;     ELEPHANT::*NUMBER-RELATION-FUNCTIONS*
>>> ;     ELEPHANT::*STRING-RELATION-FUNCTIONS* ELEPHANT::FILTER-BY-
>>> RELATION
>>> ;     ELEPHANT::FILTER-INSTANCE
>>> ;
>>> ; compilation unit finished
>>> ;   caught 49 WARNING conditions
>>> ;   caught 2 STYLE-WARNING conditions
>>> ;   printed 805 notes
>>> NIL
>>> -----------
>>> after that, tried to test:
>>> (setf *test-db-spec* '(:BDB "/tmp/db/"))
>>> (open-store *test-db-spec*)
>>> -----------
>>> invalid number of arguments: 1
>>>  [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]
>>>
>>> Restarts:
>>> 0: [RETRY] Retry SLIME REPL evaluation request.
>>> 1: [ABORT] Return to SLIME's top level.
>>> 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread"
>>> RUNNING {B7170D1}>)
>>>
>>> Backtrace:
>>> 0: (DB-BDB::%DB-ENV-CREATE #<unavailable argument> #<unavailable
>>> argument>)[:EXTERNAL]
>>>     Locals:
>>>       SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
>>>       SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
>>>       SB-DEBUG::ARG-2 = :<NOT-AVAILABLE>
>>> 1: (DB-BDB::DB-ENV-CREATE)
>>>     [No Locals]
>>> 2: ((SB-PCL::FAST-METHOD ELEPHANT::OPEN-CONTROLLER
>>> (DB-BDB::BDB-STORE-CONTROLLER)) #<unavailable lambda list>) 
>>> [:EXTERNAL]
>>>     [No Locals]
>>> 3: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
>>> SB-INT:&MORE SB-PCL::.DFUN-MORE-CONTEXT. SB-PCL::.DFUN-MORE-COUNT.))
>>> ..)
>>> 4: (OPEN-STORE #<unavailable lambda list>)[:EXTERNAL]
>>> 5: (SB-INT:SIMPLE-EVAL-IN-LEXENV (OPEN-STORE *TEST-DB-SPEC*) #<NULL-
>>> LEXENV>)
>>> ---------
>>> and:
>>> EL-TESTS> (do-backend-tests)
>>> the same error.
>>>
>>> I tried elephant 1.0 stable, 0.9, sbcl 23 with the latest elephant,
>>> but every time it gives another error, 0.9 crashes miserably,
>>> resulting in a memory overload.
>>>
>>> What are the exact prerequisities you use on a running system?
>>> Any idea what went wrong?
>>>
>>> Thanks a lot.
>>>
>>> /o>
>>> |/
>>>
>>> _______________________________________________
>>> 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
>>
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel




From rastandy at inventati.org  Mon Mar 16 01:21:06 2009
From: rastandy at inventati.org (Andrea Russo)
Date: Mon, 16 Mar 2009 02:21:06 +0100
Subject: [elephant-devel] elephant installation on sbcl 1.0.26.1
References: <544191d90903120200o6009a203idb8735256cbeaf36@mail.gmail.com>
	<A79C62CF-4ACB-4241-B60F-E16DAF4D52E7@media.mit.edu>
	<544191d90903121347l15c07e05hdd26b41853da76a5@mail.gmail.com>
	<86prgi1gjq.fsf@inventati.org>
Message-ID: <863ade1cvx.fsf@inventati.org>

Andrea Russo <rastandy at inventati.org> writes:

> Hi,
>
> mosi <amosat+lisp at gmail.com> writes:
>
>> it works!
>
> Can you please describe how you get rid of the "Invalid argument" error?

Sorry, I really meant: the "invalid number of arguments" error.

Bye,
Andrea.

-- 
Reclama i tuoi diritti digitali, elimina il DRM.  Approfondisci su
http://www.no1984.org
Reclaim your digital rights, eliminate DRM.  Learn more at
http://www.defectivebydesign.org/what_is_drm




From amosat+lisp at gmail.com  Mon Mar 16 10:18:15 2009
From: amosat+lisp at gmail.com (mosi)
Date: Mon, 16 Mar 2009 11:18:15 +0100
Subject: [elephant-devel] elephant installation on sbcl 1.0.26.1
In-Reply-To: <863ade1cvx.fsf@inventati.org>
References: <544191d90903120200o6009a203idb8735256cbeaf36@mail.gmail.com>
	<A79C62CF-4ACB-4241-B60F-E16DAF4D52E7@media.mit.edu>
	<544191d90903121347l15c07e05hdd26b41853da76a5@mail.gmail.com>
	<86prgi1gjq.fsf@inventati.org> <863ade1cvx.fsf@inventati.org>
Message-ID: <544191d90903160318s19305488k173006bea906fb50@mail.gmail.com>

Hi Andrea,
I`m not at my linux machine, but as far as I can rememeber these were the step