Nikos, No, never tried ufs. Anyway, the performance issues with ext3 in particular were supposed to happen on store _startup_ afaik.
Regards, Alejandro 2008/12/8 Nikos Balkanas <[EMAIL PROTECTED]> > Dear Alej, > > I just did a couple of runs on Solaris w/ ufs logging/no logging. 1000 > threads x 1000 msgs each (1000000 MTs) with DLRs over ppg (fake smsc). Time > quoted is time to get PAP response from ppg. > > logging: 17':35. 1000000 SMS + 1000000 DLRs sent. > no-logging: 11':53. 22000 SMS + 22000 DLRs sent. It took over 1hr for the > queue to empty. > > Overall seems logging is synchronous, no-logging is asynchronous and takes > much longer to complete. > > Did you have similar experiences with no-logging? How was the queue at the > end of the run? > > Thanx, > Nikos > > ----- Original Message ----- > *From:* Nikos Balkanas <[EMAIL PROTECTED]> > *To:* Alejandro Guerrieri <[EMAIL PROTECTED]> > *Cc:* Tony Kirkham <[EMAIL PROTECTED]> ; [email protected] > *Sent:* Thursday, December 04, 2008 2:52 AM > *Subject:* Re: Removing an erroring message stuck in queue / file store > > It goes without saying. In a production system with large queues, every > little detail must be addressed. A suitable indexed filesystem (i.e. > ReiserFS) should be used for the spool. > > Cheers, > 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:44 AM > *Subject:* Re: Removing an erroring message stuck in queue / file store > > Yes, most of the time. The only exception seems to be if you're using some > journaled filesystems (e.g. ext3), and your spool holds a lot of messages. > The system would take some time to come up if there's a lot of messages > enqueued when starting. We're talking about tenths of thousands messages on > the queue, not just a few hundreds. > > Using xfs or ext2 avoids that. > > Other than that, at least in my own experience the spool folder is quite > easier to maintain imho. > > Regards, > > Alejandro > > 2008/12/3 Nikos Balkanas <[EMAIL PROTECTED]> > >> 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 >>>>>> >>>>> >>>>> >>>> >>> >> >
