Hello,
Thanks for the quick reply!
>
> Now priorities are ignored in AP4R('s dispatchers). I want to know how
> you intend
> to use priorities or how differently treat them.
>
We're looking at having in total around 30 or so different actions we'll
be calling through ap4r, some of these we will want to run within a few
minutes of being submitted (as soon as possible essentially), others are
far less time-sensitive. The running time of these will vary from
under a
second (email sending for example) to 30+ minute datacrunching routines.
Most of the time sensitive ones cluster neatly into one or two classes
so they'll get dedicated queues/threads/servers but it would be
useful to be able
to further prioritise certain messages as we move towards
there always being something waiting in the queue. Being able to do that
would take some of the pressure off us to analyse load and ensure we've
balanced requirements in different areas correctly by hand as things
scale.
> AP4R doesn't support it now. Which side, client(async_to) side or
> server
> (dispatchers) side, do you need repeating?
>
Server-side. Some of all these processes will be client-initiated
but most we will want to run on schedules ranging from every 10
minutes to every 24 hours. Obviously we can do this easily enough
through cron and some small scripts but it would be neat to be able
to simply load in those messages at init and be confident
they're going to be run without worrying about another process.
>
>
>> Any ballpark timeframe on stable carriers?
>>
>
> It's very difficult :-< . With carriers, there may happen
> pitch-and-catch of messages
> between AP4R servers. The present implementation is rather naive, I
> think.
>
It is certainly is a complex problem. When you say pitch-and-catch
are you
imagining something where client servers poll a central server which
then
sends them a message which they then acknowledge receiving or something
much more peer-to-peer? I guess the only system that would be
resistant to
a single point of failure would be if the servers sending messages
were aware
of a pool of ap4r servers, all of which accepted messages then passed
them amongst
themselves. Not a simple job though!
Cheers,
Alex
_______________________________________________
ap4r-user mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ap4r-user
