Re: store files - store_load
"fred" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <002d01c5cae1$9814f5d0$0401a8c0@FRED4> |
----- Original Message ----- From: "Alexander Malysh" <[email protected]> To: <[email protected]> Sent: Thursday, October 06, 2005 11:50 PM Subject: Re: store files - store_load -#- MailID:PAAA > Hi, > > fred wrote: > > Hi devel groupers > > > > > > I have been testing with a few fail scenarios lately, and the way the > > code is currently doesn;t > > quite do it for me, strange because much of the way its coded has been > > like that for quite some time...... > > > > 1.) Firstly during init_bearerbox, the store_init - which starts up the > > store_dumper thread, > > which has a tendency to run the store_dump() and thus do_dump and rename > > the say > > "kannel.store" to "kannel.store.bak" > > and the new store is renamed to "kannel.store" > > you are right, it's a race condition here (but unfortunately not only > one in store-file support)... > > > > > 2.) now the store_load() is run, the "kannel.store" now read is > > typically 0 length > > I have actually changed the code to like > > if (store_file != NULL && octstr_len(store_file)!=0) > > info(0, "Loading store file `%s'", octstr_get_cstr(filename)); > > else { > > store_file = octstr_read_file(octstr_get_cstr(newfile)); > > so it gets to "kannel.store.bak" and loads these messages, > > it's workaround but not properly fix. agree, which is why the following is best > > > > > > 3.) however, rationally I think the order of how its happening is all > > wrong, and would rather have > > store_load as deterministically being the first thing to run which is > > how i am changing it to. > > > > the order is not wrong. Only thing that I would change, is: start dumper > thread after store_load completed, means at the and of store_load function. Yes, thats what I meant and did and works much better. > > > 4.) theres a few other things i'm going to say about message > > acknowledgement...but I'll make that another subject > > ITNTDF > > hmm, interesting to hear about... > > > > > I would like to know what current scenario of recovery the existing code > > has been tested for..??? anyone? > > > > it was tested for most cases but it's not bug free! I personally know > some strange race conditions within store-file support that not too hard > to fix and will be fixed as soon I have time for it hopefully by the end > of this week :-) In the meantime you could test my new store spool > replacement that was posted to this list. > > > Anyway.......I written this stuff here so you can comment on what I > > said......I changed stuff anyway for our version........ > > hmm, it's open source if you still didn't get it... so patch is welcome... hmm,yeh but making a diff -u that will make sense to you is a bit of a problem...after doing custom stuff, and I tend to reformat the code in places I need to be able to read and follow it. > > Thanks, > Alex > > > > > > > Cheers > > > > > >