[DGD]Problem with state-dump

[Felix A. Croes]

balduin at uni-paderborn.de wrote:

> After dworkins hint how to handle more than 64k objects with
> dgd, i now decided to use dgd's state-dump for object 
> persistency and use the database for indexing purposes only.
>
> I currently have some problems with this:
>
> - When I first did a dump_state() followed by a shutdown(),
>   I noticed after restart, that the connection objects
>   (cloned by connection() in e.g. the telnet port object to 
>    represent the connection) (oops many "connection"s in this sentence)
>   where still existent. I now close down all connections
>   when preparing dump_state() to avoid dumping them.

It is best not to close them in advance, but to store a copy of users()
in the driver object just before every state dump, so you can destruct
the objects on a restore.


>[...]
>   Nevertheless the server is shutting down and the dump-file seems to
>   be ok. But i'd like to have a clue what is happening.

shutdown() doesn't abort the current thread.  Rather, it takes action
immediately after the current thread has completed.  The same is true
for dump_state().


> - This leads to the next problem. I'd like to do a state-dump once in
>   a while, just to reduce my risk in case of emergency. Lets say shortage
>   of electricity. Or a server crash during development. Is there a way
>   to do this without saving/loosing the connection objects to avoid the 
>   object leak mentioned above ?

Yes, destruct the connection objects immediately after a restore
instead of before creating a state dump.


> - And the last question concerning state-dump. I tested the performance
>   of dump_state with 90000 (empty) objects. This is fast (about 9 seconds),
>   but the time it takes seems to be independend from the number of objects
>   touched since the last dump_state() or swapout(). Is there a way to do
>   an incremental state-dump file ?

There is no incremental state dump.  The time it takes to dump state
depends on the number of objects in memory, not on objects that are
currently swapped out.  If you reduce memory usage by assigning giving
a smaller value to the swap_fragment config parameter, dumping state
will take less time.

If you just created those 90000 objects, many of them may still be in
memory.  To test real behaviour, give your mud a chance to swap out
most of them before creating the state dump.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd