high and normal priorities already exists, I think low priority is usefull too - adding many low-priority messages to queue will not affect speed of delivery for all other messages.

high can be used for critical mesages (like error messages).
low - for non-time-critical (like monthly reports or other periodical mass sending).
normal - all other

I have to think about this.

Perhaps there should be also a setting like low_priority_max_delay defined, because otherwise messages with a low priority are never sent, as long as there are always normal priorized messages available. Or it may take too long before low priorized messages are sent, but of course "low" means "low". For example, a low priorized message could change to normal priority, if it has been waiting more than 12 hours.

However, with a large number of messages in the spooler, like 10 000, the checking of the priority is too slow. Because of this, there is another undocumented setting available, "ignore_outgoing_priority". But then nothing is checked.

Probably I may enhance this feature: the mainspooler can check the header as it does now, but it could use the file name to indicate to the modem processes, what is a priority. One more setting, again , is required, but then files could be like "high-priority-send_XXXX", or just "send_XXXX" and there is not need to read files when finding a next file to send.

Any comments? ( not yet started the coding... )

keke wrote

However, with a large number of messages in the spooler, like 10 000, the checking of the priority is too slow

may be splitting messages with different priorities to separate queues (directories) can help?

for example several 'checked' directories - modem process search in high-priority directory, if empty - swtich to normal-priority, if empty - to low-proirity.

keke wrote

Probably I may enhance this feature: the mainspooler can check the header as it does now, but it could use the file name to indicate to the modem processes, what is a priority. One more setting, again , is required, but then files could be like "high-priority-send_XXXX", or just "send_XXXX" and there is not need to read files when finding a next file to send.

Ghmm....
Mix messages headers and file names - you think it is good approach?

keke wrote

For example, a low priorized message could change to normal priority, if it has been waiting more than 12 hours.

I like it

edo wrote

keke wrote

However, with a large number of messages in the spooler, like 10 000, the checking of the priority is too slow

may be splitting messages with different priorities to separate queues (directories) can help?

Yes, but then lot of directories must be defined and the queue sorting should be modified too.

edo wrote

for example several 'checked' directories - modem process search in high-priority directory, if empty - swtich to normal-priority, if empty - to low-proirity.

That's what the modem processes do currently with queues. If some external application does the sorting, or messages are spooled by the checkhandler, this will work but "low_priority_max_delay" will not work without an external process or something.

edo wrote

keke wrote

Probably I may enhance this feature: the mainspooler can check the header as it does now, but it could use the file name to indicate to the modem processes, what is a priority. One more setting, again , is required, but then files could be like "high-priority-send_XXXX", or just "send_XXXX" and there is not need to read files when finding a next file to send.

Ghmm....
Mix messages headers and file names - you think it is good approach?

I'm not sure whether it is a good approach... I started my first answer with "I have to think about this."...

But it may be a good. Mainprocess, users and front-end applications use the headers like they do now, but "internally" smsd uses filenames to save the time and the processor. But still, I have to think...

edo wrote

keke wrote

For example, a low priorized message could change to normal priority, if it has been waiting more than 12 hours.

I like it

I agree.

keke wrote

That's what the modem processes do currently with queues. If some external application does the sorting, or messages are spooled by the checkhandler, this will work

great

keke wrote

but "low_priority_max_delay" will not work without an external process or something.

perhaps it is not so bad?