Tony, Just a quick update on store file internals. I've been checking the code a little and the dumping of messages doesn't occur on each message change, but on a separate thread at given time intervals (something like every 30 seconds I think).
That being said, I personally prefer the spool folder over the store file. It's more like a "Maildir over Mailbox" approach. The spool has a little more I/O stress (each message is updated/deleted at the moment of the change, compared to dumping the whole file at given intervals) but on the other side there's a lot less of locking going on. The only issue to keep in mind is the performance on journaling filesystems, but that only shows up on heavily loaded scenarios (maybe handling hundreds of thousands messages a day or more) so if you're not dealing with high traffic it won't be a problem at all. If you're planning your setup you can consider having a dedicated ext2 or xfs partition for this anyway. The spool folder was introduced time ago (more than a year I think) but it was after 1.4.1 was out, so you need a CVS version to take advantage of this. Anyway, I think a new stable release it's not far away. CVS code is as stable as 1.4.1 imho, I've been using it on production systems for years without a single problem. Regards, Alejandro Guerrieri On Thu, Dec 4, 2008 at 1:39 PM, Tony Kirkham <[EMAIL PROTECTED]> wrote: > Thanks, guys. This is a lot of great information. I will be trying this > and I will post my results. > > One other question though, are there any advantages to the file store over > the spool store? Before this conversation, I had not understood what the > spool store was. I had only heard the term mentioned in passing. I have > been using older documentation (Kannel 1.4.1 User's Guide) that lists a > parameter to the core configuration of "store-file" and that is what is > currently in my config file and running on my system. The actual Kannel > code I am using is a CVS pull of Kannel from June of this year. Now that I > examine the latest, sort of, documentation (cvs-20081125) I no longer see > the "store-file" parameter. Instead I see "store-type" and > "store-location". > > I am assuming, now, that the spool storage type is a "recent" addition to > Kannel and was added because it worked more effeciently than trying to > rewrite a single file containing many messages. Is this assumption > correct? > > Now that I know about the spool storage type I think I will be switching to > it. I can't currently see any advantage the file store has over the spool > type and I see many disadvantages, the impetus of this entire conversation, > to name one. I am now wondering if my June Kannel code has these parameters > in it or if I will have to get a more recent code base and recompile. Any > thoughts? > > Thanks again, > > -Tony > > > > 2008/12/3 Nikos Balkanas <[EMAIL PROTECTED]> > >> Definitely. I have a test kannel, hooked to fakesmsc, and I would always >> try out a copy of the "fixed" store file before commiting it. There is no >> header from what I can see, however there is a footer that has a list of all >> message ids. This is a bit more complex, not much though. I presumed that >> there was no CRC or indexing. It seems that the message has to be removed >> both from the body and the footer. >> >> Tony if you are watching this, a simple cat at the end won't do it, but >> something similar should. >> >> The footer has to be removed and saved in a different file. Then do the >> cat and insert the saved footer just before the new footer, so that the >> right order is preserved. >> >> Of course it goes without saying that the procedure has to be tested first >> on a test environment with fakesmsc. I could do it, except that i don't have >> any real messages. >> >> BR, >> Nikos >> ----- Original Message ----- >> >> *From:* Alejandro Guerrieri <[EMAIL PROTECTED]> >> *To:* Nikos Balkanas <[EMAIL PROTECTED]> >> *Cc:* Tony Kirkham <[EMAIL PROTECTED]> ; [email protected] >> *Sent:* Thursday, December 04, 2008 4:20 AM >> *Subject:* Re: Removing an erroring message stuck in queue / file store >> >> Hmm, I'm not 100% sure you can append messages at the end of the store and >> get away with it... I'd first try it on a staging server. >> >> You can surely "merge" new messages on a spool by copying (you need to >> restart kannel for it to notice the new messages, though) but I don't know >> if is there any "header" or "footer" information on the store files that >> would break the format if appended together. >> >> I'm not saying it's not possible, just that I've never tried it and since >> I'm not _that_ fluent on the file store internals I cannot tell for sure. >> >> Regards, >> >> Alejandro >> >> 2008/12/3 Nikos Balkanas <[EMAIL PROTECTED]> >> >>> BTW, Tony. It doesn't seem that you will have significant downtime. If >>> Alej is right you can just stop kannel momentarily to grab the store files >>> and start it again. Once the problematic store files are fixed you can just >>> stop kannel momentarily and "cat kannel.store.fixed >> kannel.store". Do the >>> same for kannel.store.back and restart kannel. Just don't change from >>> storefile to spool during the process. >>> >>> So you don't loose any messages and downtime can be minimal. Cool right? >>> >>> ----- Original Message ----- >>> *From:* Nikos Balkanas <[EMAIL PROTECTED]> >>> *To:* Alejandro Guerrieri <[EMAIL PROTECTED]> ; Tony Kirkham<[EMAIL >>> PROTECTED]> >>> *Cc:* [email protected] >>> *Sent:* Thursday, December 04, 2008 2:35 AM >>> *Subject:* Re: Removing an erroring message stuck in queue / file store >>> >>> Thanks for pointing that out. Still it is easy to preview in "vim -b" >>> (not hex) and can identify *any* of the fields Sender, recipient, text, >>> messageID, so if anyone is missing there are a lot of matches in ASCII. The >>> binary text is easy and straightforward. One can reasonably find the borders >>> (patterns) of the previous and next message (presumably intact) and delete >>> the in between. >>> >>> Tony, if the file is small enough to send through mail (zipped) and don't >>> feel like trying it yourself, why don't you send it to me along with the >>> message details to see what I can do about it. >>> >>> Alej from your words it seems that a spool directory is more efficient >>> than a storefile. If anytime kannel sends a message has to delete and >>> rewrite almost the whole store file, it is a big waste. Isn't so? >>> >>> BR, >>> Nikos >>> >>> ----- Original Message ----- >>> *From:* Alejandro Guerrieri <[EMAIL PROTECTED]> >>> *To:* Nikos Balkanas <[EMAIL PROTECTED]> >>> *Cc:* Tony Kirkham <[EMAIL PROTECTED]> ; [email protected] >>> *Sent:* Thursday, December 04, 2008 2:18 AM >>> *Subject:* Re: Removing an erroring message stuck in queue / file store >>> >>> The 20 nulls are probably a lot of empty/unused fields, that doesn't >>> necessary means that they'll be always empty... so don't assume that there >>> should be that much. It's not a separator, just a pattern in your particular >>> message queue set. >>> >>> When you edit, you have to make sure that you're actually cutting on the >>> right places. Alas, if the message is in fact corrupted maybe it's not >>> complete, so YMMV. >>> >>> Using the spool file is way easier, of course. Again, if you have a >>> "broken" message (why is that it's another question) it's just a matter of >>> determining which one is causing the problem and removing it. >>> >>> Regards, >>> >>> Alejandro >>> >>> 2008/12/3 Nikos Balkanas <[EMAIL PROTECTED]> >>> >>>> Hi, >>>> >>>> Just out of curiosity I openned a store file and it doesn't seem too >>>> difficult. You can edit it easily with "vim -b" and there are a lot of >>>> ASCII >>>> fields (sender, recipient, messageid), so you can search for your message >>>> easily. Each message seems to be bordered by 20 '\0' (NULLS). Can't miss >>>> them. Find offending message and delete by hand (assuming that you know >>>> which message is the offending one). >>>> >>>> This again assumes that there is no CRC or indexing of the messages as >>>> discussed by Alejandro. In other words, you can safely remove any message. >>>> >>>> Make a backup, try it and let us know of the result. Stop kannel, and >>>> repeat for both files. >>>> >>>> Cheers, >>>> Nikos >>>> >>>> ----- Original Message ----- >>>> *From:* Alejandro Guerrieri <[EMAIL PROTECTED]> >>>> *To:* Tony Kirkham <[EMAIL PROTECTED]> >>>> *Cc:* [email protected] >>>> *Sent:* Wednesday, December 03, 2008 7:14 PM >>>> *Subject:* Re: Removing an erroring message stuck in queue / file store >>>> >>>> Ah, you're using the "file" store, not "spool" maybe? >>>> >>>> AFAIK, there's no document on the storage format. It's mainly a dump >>>> from the "Msg" structure, but the "Octstr" objects can have nulls in the >>>> middle, so it's not as easy to parse and, it doesn't have a fixed length >>>> and >>>> (if you're still willing to venture at it) you'll need an hex editor if you >>>> don't want to mess the whole file (the nulls in the middle of the file will >>>> probably render any text editor unusable). >>>> >>>> If you use the "spool" store, each message is stored on an independent >>>> file on a directory tree. Removing the file removes the message. >>>> >>>> The only problem is that kannel only uses the files as a backup >>>> mechanism and it doesn't refresh it during runtime. To clarify: >>>> >>>> * When a message arrives (or is enqueued to be sent), kannel adds it to >>>> an in-memory queue and stores a copy on disk. An internal uuid is used to >>>> keep track of messages on both places. >>>> >>>> * When kannel ends processing the message, it removes it from the >>>> in-memory queue and deletes the message from disk. Depending on the store >>>> type being used, this means removing it from the store file and rewriting >>>> the file, or remove an entire file from the spool tree. >>>> >>>> * If kannel crashes or is shutdown with messages pending, the messages >>>> are kept on the file/spool queue. During a shutdown, the in-memory queue is >>>> dumped to file again afaik. >>>> >>>> * When kannel starts, it first load the messages from the file/spool >>>> queue. >>>> >>>> * On the particular case of the file store, a backup file is kept at all >>>> times in case the main file is deleted or corrupted. >>>> >>>> So, from the above, it's clear why you need to stop kannel before >>>> deleting the file(s). >>>> >>>> You can stop kannel, delete the store and store.bak files, or remove the >>>> whole spool tree and start again. It will remove ALL your pending messages. >>>> If you can figure out which message is causing the problem, you can remove >>>> it from the spool (if you're using the spool store) as well. With the file >>>> store, you'd need to figure out from the binary, which is near to >>>> impossible >>>> without some specially crafted tools imho. >>>> >>>> Regards, >>>> >>>> Alejandro >>>> >>>> On Wed, Dec 3, 2008 at 1:15 PM, Tony Kirkham <[EMAIL PROTECTED]>wrote: >>>> >>>>> How? By hand, in my favorite editor? I have tried this, with bad >>>>> results. There are special characters, at least vi displays them that >>>>> way, >>>>> that I can't interpret so I do not know where, exactly, one message stops >>>>> and the next starts. Is there a document that describes the store file in >>>>> detail? >>>>> >>>>> -Tony >>>>> >>>>> >>>>> On Tue, Dec 2, 2008 at 4:08 PM, Alejandro Guerrieri < >>>>> [EMAIL PROTECTED]> wrote: >>>>> >>>>>> And do it without kannel running, of course ;) >>>>>> >>>>>> If you're using the spool store file, you can remove the individual >>>>>> message (assuming that you can find out what's the message causing the >>>>>> error). >>>>>> >>>>>> Regards, >>>>>> >>>>>> Alejandro >>>>>> >>>>>> >>>>>> On Tue, Dec 2, 2008 at 5:49 PM, info.ubichip <[EMAIL PROTECTED]>wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> when you trash the .store file, don't forget to remove the .store.bak >>>>>>> as well otherwise, it will retry to send all the remaining message. >>>>>>> >>>>>>> regards >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> *From:* Tony Kirkham [mailto:[EMAIL PROTECTED] >>>>>>> *Sent:* lundi 1 dĪ¹cembre 2008 21:32 >>>>>>> *To:* [email protected] >>>>>>> *Subject:* Removing an erroring message stuck in queue / file store >>>>>>> >>>>>>> Is there a way to remove a message from the file store that is >>>>>>> erroring continuously allowing the other messages to be sent? >>>>>>> >>>>>>> If I simply restart Kannel sometimes the other messages get sent and >>>>>>> sometimes they do not. Why is that? >>>>>>> If they all get sent but the erroring message I can simply replace >>>>>>> the file store with another file with a restart of Kannel, but I would >>>>>>> like >>>>>>> to know if there is a way to remove the message by some other means. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> -Tony >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
