>> the queue will attempt to call the webservice up to 10 times or until
>> the message expires in an hour. Also, these messages have a priority
>> of 1 so they will be processed before messages in the queue with a
>> lower priority - I believe the default is 0.

I assume this is happening entirely in reliable-msg code? How hard would
it be given that to allow it to be taken into account for all messages?
Something as simple as modifying stale_queue do the job? I've only taken
a very cursory look over the code.

> Nice example! Because a :repeated delivery quality is just in the  
> reliable-msg's
> QueueManager, AP4R can utilize it for free :-)
>
> But I don't understand priority issue yet, it is related to Selector
> which describe the
> interaction between Queue(client) and QueueManager(server).
>
> Suppose the case messages with low and high priorities are mixed and
> high priority messages constantly. If high priority messages were  
> processed
> before lower ones all the time, lower ones may not be processed for  
> a long time.
> So there should be some balance between "skipping" and "acceptance"
> (e.g. according to hang-up time etc.).
>
> It's a case dependent issue, but if there are somewhat general use  
> cases,
> I do incorporate it into AP4R. Otherwise I should arrange some hook.

What could work would be some kind of optional arbitary 'load' number  
that
reflects roughly how long running or resource-intensive a process is  
so there
would be 3 factors taken into account when choosing the next message to
process - how long each message has been waiting, what level of priority
it has and whether it's going to use up half of cpu for an hour or  
not. That
way a low priority message that won't take more than 10 seconds can
be squeezed in between higher priority processes after a while if there
isn't any free dispatchers.

That is however a whole new level of complexity. Simple priority and
effective queue number balancing is probably more than enough to  
handle the
issue for the vast majority of use-cases.

Thanks again!
Alex


_______________________________________________
ap4r-user mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ap4r-user

Reply via email to