You are right - not a good idea. ok, try this on for size :
- The store mechanism works like before, where each message and ack/nack are first
dumped to storage before doing anything else.
- Messages are not duplicated by the SMSC drivers, but instead the driver just take a
reference to the message, and must return the reference with an ack or nack at the end
of processing.
- Messages are not destroyed after queueing to the SMSC driver, but instead kept in a
dictionary.
- Whenever an ack or nack is returned with a message it is matched against the
dictionary (after being stored, of course), and the matching message is then removed.
- The size of the store file is being monitored at all times.
- When a certain limit as been reached - be it storage size or a time limit - a
"rollover" of the store file is done, which is done as follows:
* the storage is locked
* the store file is renamed
* a new store file is craeted (with the old name) and all messages in the
dictionary are dropped into it
* the storage is released
* the old store file is deleted.
- While the store is locked in "rollover", no messages can be written to the storage.
I don't think its such a big deal, because only one message can wait on the storage at
any given time (if there are more then they are queued in the smsbox). also the
rollover should be pretty quick as it's mostly a not so big buffered IO write
(probably a few Ks at the most under normal conditions and an average load).
- When the bearerbox recovers from a crash it should try to read the backup file, and
if succesful (meaning the box crashed in the middle of a rollover), delete the regular
storage. else read the regular storage.
There are some loose ends here, but it's not so terrible, and assuming fast enough
processing (which is feasable in all but the most execptional conditions) we should be
safe enought
An alternate approach would be to simply store messages to an alternate file, and then
harvest the original file in a background low priority thread, store all the non-acked
messages from the original file in the new file, and then delete the original. this
approach is "safer", but it also more complicated as we could crash while we have the
same message in both files, and also this way messages may be written into storage
after their acks. this forces us to a much slower and ellaborate synchronization
process on recovery which can elliminate duplciates and also remember acks until their
messages are found later.
--
Oded Arbel
m-Wise Mobile Solutions
[EMAIL PROTECTED]
Mobile: +972-67-340014
Tel: +972-9-9581711 (ext: 116)
::..
"From the moment I picked your book up until I laid it down I was convulsed with
laughter.
Some day I intend reading it."
-- Groucho Marx (1895-1977)
> -----Original Message-----
> From: Kalle Marjola [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 14, 2002 10:27 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Message store (Was: EMI: Serious Problem PANIC:
> Too manyconcurrentallocations)
>
>
> On Thu, 13 Jun 2002, Oded Arbel wrote:
>
> > You also don't need to store acks in the store, as only
> unacked messages
> > are stored there.
>
> But note that if you do not store them, you have to write the
> entire store
> each time you get ack or if your system goes down between two
> writes, it
> will resend all messages ackked after the last write.
>
> --
> &kalle marjola
>
>
>
