Shino, Alex,
It seems that the priority and repeated delivery provided by
reliable-msg can be taken advantage of through apr's rm_options. For
example, when I send the following:
{ :dispatch_mode => :SOAP,
:queue_name => 'queue.messages',
:delivery => :repeated,
:expires =>3600,
:max_deliveries=>10,
:priority => 1 },
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 haven't been able to figure out if there is a way to delay the retry
attempts with reliable-msg. I've had issues when restarting the server
and the queue will process all 10 failures before the server is
accepting request. Does anyone know if this type of functionality
exists in reliable-msg?
Btw, I've had the same issue happen when restarting a queue. I think
it would be nice to add in a retry delay to the ap4 client.
Oh and if you haven't already make sure to check the following posts
on the reliable-msg forum, regarding mysql connection timeouts
http://rubyforge.org/forum/forum.php?thread_id=11656&forum_id=4548
I'd like to thank the ap4r team for all their efforts!
Dave
On 10/1/07, shun shino <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
> 2007/10/1, Alex Graul <[EMAIL PROTECTED]>:
> > We've chosen AP4R for our project which involves a lot of very db
> > heavy/high load processes that need to be
>
> Thank you very much for your interests in AP4R.
> I answer and comment (and ask you back :-) ) on some of your questions
> and will answer in another mail on the others.
>
> > Does AP4R support priorities from reliable-messenging? I assume 0 is
> > the lowest, is there a highest?
>
> Now priorities are ignored in AP4R('s dispatchers). I want to know how
> you intend
> to use priorities or how differently treat them.
>
> > Does AP4r support repeat messages (reliable messaging apparently
> > does, though I can find zero documentation)?
>
> AP4R doesn't support it now. Which side, client(async_to) side or server
> (dispatchers) side, do you need repeating?
>
> > 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.
>
> > Is postgres support stable?
>
> YES.
>
> > servers which then execute those messages on local threads. Can those
> > servers accept messages to a local queue as
> > well or do they just take messages over carrier?
> >
> > When we do async_to calls using the controller/action format
> > (ap4r.async_to( {:controller => ...', :action => '....'} ,,,)) the
> > message seems to keep the port number of the app that called it,
> > obviously we can specify a full url and get round this
> > but is there a more elegant solution?
>
> I will write a mail about those later.
>
> Thanks,
> shino (Shunichi Shinohara)
> _______________________________________________
> ap4r-user mailing list
> [email protected]
> http://rubyforge.org/mailman/listinfo/ap4r-user
>
_______________________________________________
ap4r-user mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ap4r-user
