Re: Bearerbox Queue (re)Design Suggestion / RFC

Alex,

How long before this patch will be available in cvs.

I would like to test it to see if it meets our needs.

Thanks,
Khary

Alexander Malysh wrote:
> Hi,
>
> no, please no DB things in bearerbox. It should be possible to set minimal
> outgoing queue limit (I have patch for this, I have to rebase it against
> current cvs) and use something like sqlbox.
>
> So the chain would be:
>
> smppbox -> DB -> sqlbox -> bearerbox
>
>
> Khary Sharpe wrote:
>
>   
>> Hi Guys,
>>
>> Firstly I would like to say thank you for a wonderful product, and keep
>> up the good work.
>>
>> I work with a company that is essentially an SMSC proxy (using kannel
>> with smppbox).
>>
>> We have several thousands of messages passing through our system and
>> want a way to better handle the traffic.
>>
>> Functionality:
>>
>>    1. Removing unwanted message - e.g. Someone accidentally send out
>>       50000 bulk alert service message
>>    2. Prioritizing messages - e.g. Service requiring priority of others
>>       e.g. a 119 (aka 911) reply message going out.
>>    3. Postdated messages - Send at future date
>>    4. Message on hold - Hold message in queue until we are ready to send
>>       them out.
>>    5. View Message Content - Allow for you to look ahead in queue and
>>       view actual messages
>>
>>
>> Suggested Implemention:
>>
>> It could be possible to use a SQLite memory table and have an interface
>> (similar to http status) that would allow for SELECT, UPDATE, and DELETE
>> queries to be passed to it, or just exposing suggested fields so there
>> would be no tampering with message content for example.
>>
>> It perhaps would be better to store it to disk our having the option for
>> a remote server like MySql. This would perhaps mean a performance hit
>> but (IMHO) the benefits would out weigh it.
>>
>> Table Design : [queue]
>>
>>     * queueId - Auto incremented integer to uniquely identify each row.
>>     * smsc-id - as the name suggests (perhaps this could be a source and
>>       destination for sms-user | wap-user | esme-user etc)
>>     * dateReceived - automatically populated upon insert
>>     * deliveryDate - same as above
>>     * priority - default value of zero, however the higher the value the
>>       higher priority
>>     * status - Pending - waiting to be sent by bearerbox; Processing -
>>       being sent by bearerbox; HELD - waiting for admin to release back
>>       to pending state
>>     * sender - shortcode
>>     * recipient - MSISDN
>>     * binaryMessage - raw message to be broadcast (I don't know how this
>>       is represented; however this could be broken down to match the
>>       internalstructure that kannel uses. )
>>
>>
>> bearerbox would then run simple queries like
>>
>> Get next message to process (or batch just by changing the LIMIT)
>>
>> Essential lock record for processing:
>> UPDATE queue SET status= 'PROCESSING' WHERE deliveryDate <= now() AND
>> status = 'PENDING' LIMIT 1
>>
>> Get record locked for processing:
>> SELECT * FROM queue WHERE status = 'PROCESSING' ORDER BY priority DESC
>>
>> Administrators could then run updates like
>>
>> UPDATE queue SET status = 'HELD' WHERE sender = '5555';
>>
>> UPDATE queue SET status = 'PROCESSING' WHERE status = 'HELD' ;
>>
>> etc;
>>
>> What do you guys think of the concept?
>>
>> - Khary
>>     
>
>