From alex at mossi.co.uk  Mon Oct  1 08:24:20 2007
From: alex at mossi.co.uk (Alex Graul)
Date: Mon, 1 Oct 2007 05:24:20 -0700
Subject: [ap4r-user] A few neophyte questions
Message-ID: <28560.1191241460@mossi.co.uk>

An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ap4r-user/attachments/20071001/4e2387af/attachment.html 

From shino.shun at gmail.com  Mon Oct  1 10:15:34 2007
From: shino.shun at gmail.com (shun shino)
Date: Mon, 1 Oct 2007 23:15:34 +0900
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <28560.1191241460@mossi.co.uk>
References: <28560.1191241460@mossi.co.uk>
Message-ID: <6af2b9b80710010715g7f09b6c7q143beaecb7ac4b18@mail.gmail.com>

Hi Alex,

2007/10/1, Alex Graul <alex at mossi.co.uk>:
> 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)

From shino.shun at gmail.com  Mon Oct  1 10:15:34 2007
From: shino.shun at gmail.com (shun shino)
Date: Mon, 1 Oct 2007 23:15:34 +0900
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <28560.1191241460@mossi.co.uk>
References: <28560.1191241460@mossi.co.uk>
Message-ID: <6af2b9b80710010715g7f09b6c7q143beaecb7ac4b18@mail.gmail.com>

Hi Alex,

2007/10/1, Alex Graul <alex at mossi.co.uk>:
> 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)

From dave at interactivemediums.com  Mon Oct  1 16:30:50 2007
From: dave at interactivemediums.com (Dave Farkas)
Date: Mon, 1 Oct 2007 15:30:50 -0500
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <6af2b9b80710010715g7f09b6c7q143beaecb7ac4b18@mail.gmail.com>
References: <28560.1191241460@mossi.co.uk>
	<6af2b9b80710010715g7f09b6c7q143beaecb7ac4b18@mail.gmail.com>
Message-ID: <921b71e30710011330k1c5e78a7wf4704343d0b2e9e@mail.gmail.com>

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 <shino.shun at gmail.com> wrote:
> Hi Alex,
>
> 2007/10/1, Alex Graul <alex at mossi.co.uk>:
> > 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
> ap4r-user at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ap4r-user
>

From shinohara.shunichi at future.co.jp  Mon Oct  1 23:58:33 2007
From: shinohara.shunichi at future.co.jp (shinohara.shunichi at future.co.jp)
Date: Tue, 2 Oct 2007 12:58:33 +0900
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <28560.1191241460@mossi.co.uk>
References: <28560.1191241460@mossi.co.uk>
Message-ID: <14CE73B79D552644B7CBEF0428763DF60337C557@045MAIL.future.co.jp>

Hi Alex,

2nd reply mail to your first one.
# I'm writing this mail in Outlook (on Windows Japanase-edition),
# if there is somethin wrong please tell me.
	
>	If I'm understanding Carriers correctly we can have say one server 
>	with a queue which is then checked by other AP4R 
>	servers which then execute those messages on local threads. 

It's correct! # Sorry for poor documentation.
 
>	Can those servers accept messages to a local queue as 
>	well or do they just take messages over carrier? 

Every AP4R process is on top of reliable-msg as you know,
so it can accept messages.
As for carriers, they are just "clients" in the sense of reliable-msg.
They fetch messages from remote queues and put them into local queues
of the same name.
	
>	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? 
	
async_to uses url_for inside. I think there are two workaround.
One is to use a URL rewrite filter in dispatcher's configuration. 
There is just one document but in Japanese (Sorry again).
  http://gihyo.jp/dev/feature/01/ap4r/0002?page=5
  # Figures and code samples are in ASCII.
Example is as follows:
==== 
dispatchers:
  - targets: queue.*
    threads: 3
    modify_rules:
      url: proc {|url| url.port = 4001 + rand(3)}
====
You can rewrite :target_url by proc as you like. The block parameter "url"
is an instance of URI::HTTP.
But this proc is "eval"ed every time, so it needs to be refactored.

Another one is, somewhat brute force, redefine Ap4r::AsyncHelper::Converters::Http#make_rm_options.
rdoc is here http://ap4r.rubyforge.org/doc/classes/Ap4r/AsyncHelper/Converters/Http.html#M000077

Thanks,
shino


From shino.shun at gmail.com  Tue Oct  2 10:06:20 2007
From: shino.shun at gmail.com (shun shino)
Date: Tue, 2 Oct 2007 23:06:20 +0900
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <921b71e30710011330k1c5e78a7wf4704343d0b2e9e@mail.gmail.com>
References: <28560.1191241460@mossi.co.uk>
	<6af2b9b80710010715g7f09b6c7q143beaecb7ac4b18@mail.gmail.com>
	<921b71e30710011330k1c5e78a7wf4704343d0b2e9e@mail.gmail.com>
Message-ID: <6af2b9b80710020706v56ad6416g5369a7490a6b3f54@mail.gmail.com>

2007/10/2, Dave Farkas <dave at interactivemediums.com>:
>  { :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.

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.

> I haven't been able to figure out if there is a way to delay the retry
> accepting request. Does anyone know if this type of functionality
> exists in reliable-msg?

I haven't tried yet but there is some comment in Selector class of reliable-msg
== BEGIN QUOTATION
    # This example uses the delivery count and message creation date/time to
    # implement a simple retry with back-out:
    #
    #   MINUTE = 60
    #   HOUR = MINUTE * 60
    #   BACKOUT = [ 5 * MINUTE, HOUR, 4 * HOUR, 12 * HOUR ]
    #
    #   selector = Queue::selector { delivered == 0 ||
BACKOUT[delivered - 1] + created <= now }
== END QUOTATION

So Queue#get with Selector instance may help you.
# reliable-msg is REALLY well made library!
Two comment about this functionality.
1. can not be used through AP4R dispatcher
2. block is not able to be marshalled so it is evaluated locally by callback
  from remote druby server, so it needs some more TCP communication
  (depending of # of rejections).

> 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.

Added to my TODO list (with performance consideration).

> Oh and if you haven't already make sure to check the following posts
> on the reliable-msg forum, regarding mysql connection timeouts

I don't know about that. Thank you for your information.

Thanks,
shino

From alex at mossi.co.uk  Tue Oct  2 10:50:24 2007
From: alex at mossi.co.uk (Alex Graul)
Date: Tue, 2 Oct 2007 15:50:24 +0100
Subject: [ap4r-user] A few neophyte questions
Message-ID: <DA317799-39A4-4E6B-9D36-ACB028522E55@mossi.co.uk>

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

From alex at mossi.co.uk  Tue Oct  2 15:06:52 2007
From: alex at mossi.co.uk (Alex Graul)
Date: Tue, 2 Oct 2007 20:06:52 +0100
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <6af2b9b80710020706v56ad6416g5369a7490a6b3f54@mail.gmail.com>
References: <28560.1191241460@mossi.co.uk>
	<6af2b9b80710010715g7f09b6c7q143beaecb7ac4b18@mail.gmail.com>
	<921b71e30710011330k1c5e78a7wf4704343d0b2e9e@mail.gmail.com>
	<6af2b9b80710020706v56ad6416g5369a7490a6b3f54@mail.gmail.com>
Message-ID: <0FD548F5-B0FE-483D-A722-204C97D34801@mossi.co.uk>

>> 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



From shino.shun at gmail.com  Wed Oct  3 09:54:55 2007
From: shino.shun at gmail.com (shun shino)
Date: Wed, 3 Oct 2007 22:54:55 +0900
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <DA317799-39A4-4E6B-9D36-ACB028522E55@mossi.co.uk>
References: <DA317799-39A4-4E6B-9D36-ACB028522E55@mossi.co.uk>
Message-ID: <6af2b9b80710030654k60fe5cf6ufb9dc665a0d9b9da@mail.gmail.com>

> 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

If you have divided actions, kind of "priority" can be controlled by a
dispatchers' configuration. You can specify a set of dispatchers as
follows:
===
dispatchers:
  -
    targets: queue.very_busy.*
    threads: 10
    modify_rules:
      url: proc {|url| url.host = "busy.async.host"}
  -
    targets: queue.very_heavy.*
    threads: 1
    modify_rules:
      url: proc {|url| url.host = "heavy.async.host"}
===

This is a clipping from Japanese document. Doesn't this make sense?
# I will document it in rubyforge's wiki later.

Time-sensitive targets can be split (as targets:) and assign appropriate
threads. As options, host in URL can also be modified by modify_rules.
I hope this will be partially of help to you.

> 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.

I also feel that scheduling in messaging layer is nice idea.
There is a issue in algorithm in searching message as same as
delayed retry.
# I suppose that many inactive messages exists around head of a queue.

> 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

I imagine peer-to-peer (a peer is an AP4R process).
If every AP4R service has carriers and unprocessed messages in queues,
messages may hop (be carried) from one service to next, and then hop
to a former service or to a third service. I call it "pitch-and-catch".
May "back and forth" be adequate?
# I'm not good at English...

Thanks,
shino

From shino.shun at gmail.com  Wed Oct  3 10:03:48 2007
From: shino.shun at gmail.com (shun shino)
Date: Wed, 3 Oct 2007 23:03:48 +0900
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <0FD548F5-B0FE-483D-A722-204C97D34801@mossi.co.uk>
References: <28560.1191241460@mossi.co.uk>
	<6af2b9b80710010715g7f09b6c7q143beaecb7ac4b18@mail.gmail.com>
	<921b71e30710011330k1c5e78a7wf4704343d0b2e9e@mail.gmail.com>
	<6af2b9b80710020706v56ad6416g5369a7490a6b3f54@mail.gmail.com>
	<0FD548F5-B0FE-483D-A722-204C97D34801@mossi.co.uk>
Message-ID: <6af2b9b80710030703h6a3ec67etcbbddf66b88c9bf3@mail.gmail.com>

2007/10/3, Alex Graul <alex at mossi.co.uk>:
> >> 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
>
> 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?

If you want to specify the default rm_options, Ap4r::AsyncHelper
(in Rails plugin now) have a class variable @@default_rm_options and
its accessors.
      @@default_rm_options = { :delivery => :once, :dispatch_mode =>
@@default_dispatch_mode }

You can specify this property in environmet.rb in Rails.

HTH

shino

From shinohara.shunichi at future.co.jp  Tue Oct  9 05:30:52 2007
From: shinohara.shunichi at future.co.jp (shinohara.shunichi at future.co.jp)
Date: Tue, 9 Oct 2007 18:30:52 +0900
Subject: [ap4r-user] Enquete: Tell us how you use AP4R.
Message-ID: <14CE73B79D552644B7CBEF0428763DF60337CB90@045MAIL.future.co.jp>

Dear AP4R users,

The AP4R team have a good oppotunity to introduce AP4R at RubyConf 2007!
http://rubyconf.org/agenda.html

We plan to incorporate case examples about how AP4R is used.
If you don't mind, would you tell us your imformation about following items?

- In what system/application do you use AP4R? (ex. blog app., SBM, etc.)
- What functions do you execute asynchronously? (ex. sending mails, data generation, etc.)
- Which status is the system/appication in? (ex. developing, in operation, etc.)

In addition, any information as system configuration, rate of message flow and
(un)easy points in using, are wellcome.

# If you can tell us information as anonymous, please mail me (shino.shun at gmail.com).

P.S.
If you will kindly tell us information, we will ask you to verify our presentation material
in advance of RubyConf2007.

Thanks in advance,
shino

From sava.chankov at gmail.com  Thu Oct 11 04:31:43 2007
From: sava.chankov at gmail.com (Sava Chankov)
Date: Thu, 11 Oct 2007 11:31:43 +0300
Subject: [ap4r-user] Enquete: Tell us how you use AP4R.
In-Reply-To: <8834b7bc0710090446n646deecer3e3c06e02c122816@mail.gmail.com>
References: <14CE73B79D552644B7CBEF0428763DF60337CB90@045MAIL.future.co.jp>
	<8834b7bc0710090446n646deecer3e3c06e02c122816@mail.gmail.com>
Message-ID: <8834b7bc0710110131t35f56c75se7910950578e1d89@mail.gmail.com>

On 09/10/2007, shinohara.shunichi at future.co.jp <
shinohara.shunichi at future.co.jp> wrote:
>
> - In what system/application do you use AP4R? (ex. blog app., SBM, etc.)


Small business resource planning system written in Rails.

- What functions do you execute asynchronously? (ex. sending mails, data
> generation, etc.)


Sending SOAP messages to inventory system.

- Which status is the system/appication in? (ex. developing, in operation,
> etc.)


Operational since August 2007.

In addition, any information as system configuration, rate of message flow
> and
> (un)easy points in using, are wellcome.


Serves 4-5 messages a day. Deployed on CentOS.


Thanks in advance,
> shino
>

You are welcome,
Sava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ap4r-user/attachments/20071011/189b3269/attachment.html 

From shino.shun at gmail.com  Thu Oct 11 09:06:47 2007
From: shino.shun at gmail.com (shun shino)
Date: Thu, 11 Oct 2007 22:06:47 +0900
Subject: [ap4r-user] Enquete: Tell us how you use AP4R.
In-Reply-To: <8834b7bc0710110131t35f56c75se7910950578e1d89@mail.gmail.com>
References: <14CE73B79D552644B7CBEF0428763DF60337CB90@045MAIL.future.co.jp>
	<8834b7bc0710090446n646deecer3e3c06e02c122816@mail.gmail.com>
	<8834b7bc0710110131t35f56c75se7910950578e1d89@mail.gmail.com>
Message-ID: <6af2b9b80710110606i496b5682md1b68597a417c856@mail.gmail.com>

Hi Sava,

Thank you very much for nice information!

2007/10/11, Sava Chankov <sava.chankov at gmail.com>:
> On 09/10/2007, shinohara.shunichi at future.co.jp
> Small business resource planning system written in Rails.
> Sending SOAP messages to inventory system.

May I ask sone questions? Is the inventory system already existing system?
If so, does it have built-in SOAP handling by itself?

What kind of a message store do you use, MySQL?

# If there may be the trouble in answering, please put by. :-)

> Operational since August 2007.

Great! That pleases me!

Best regards,
shino

From sava.chankov at gmail.com  Thu Oct 11 09:42:20 2007
From: sava.chankov at gmail.com (Sava Chankov)
Date: Thu, 11 Oct 2007 16:42:20 +0300
Subject: [ap4r-user] Enquete: Tell us how you use AP4R.
In-Reply-To: <6af2b9b80710110606i496b5682md1b68597a417c856@mail.gmail.com>
References: <14CE73B79D552644B7CBEF0428763DF60337CB90@045MAIL.future.co.jp>
	<8834b7bc0710090446n646deecer3e3c06e02c122816@mail.gmail.com>
	<8834b7bc0710110131t35f56c75se7910950578e1d89@mail.gmail.com>
	<6af2b9b80710110606i496b5682md1b68597a417c856@mail.gmail.com>
Message-ID: <8834b7bc0710110642k5eb4ac51l2b42719c1b978e93@mail.gmail.com>

On 11/10/2007, shun shino <shino.shun at gmail.com> wrote:
>
> Hi Sava,
>
> Thank you very much for nice information!
>
> 2007/10/11, Sava Chankov <sava.chankov at gmail.com>:
> > On 09/10/2007, shinohara.shunichi at future.co.jp
> > Small business resource planning system written in Rails.
> > Sending SOAP messages to inventory system.


Hi Shino,

May I ask sone questions? Is the inventory system already existing system?


Yes.

If so, does it have built-in SOAP handling by itself?


Yes.

What kind of a message store do you use, MySQL?


No, file based.

cheers,
Sava
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ap4r-user/attachments/20071011/bac57c25/attachment.html 

From shinohara.shunichi at future.co.jp  Wed Oct 17 20:15:38 2007
From: shinohara.shunichi at future.co.jp (shinohara.shunichi at future.co.jp)
Date: Thu, 18 Oct 2007 09:15:38 +0900
Subject: [ap4r-user] test mail
Message-ID: <14CE73B79D552644B7CBEF0428763DF60356E7F1@045MAIL.future.co.jp>

no body

shino

From shinohara.shunichi at future.co.jp  Thu Oct 18 22:13:40 2007
From: shinohara.shunichi at future.co.jp (shinohara.shunichi at future.co.jp)
Date: Fri, 19 Oct 2007 11:13:40 +0900
Subject: [ap4r-user] A few neophyte questions
In-Reply-To: <6af2b9b80710030654k60fe5cf6ufb9dc665a0d9b9da@mail.gmail.com>
References: <DA317799-39A4-4E6B-9D36-ACB028522E55@mossi.co.uk>
	<6af2b9b80710030654k60fe5cf6ufb9dc665a0d9b9da@mail.gmail.com>
Message-ID: <14CE73B79D552644B7CBEF0428763DF60356E986@045MAIL.future.co.jp>

> If you have divided actions, kind of "priority" can be controlled by a
> dispatchers' configuration. You can specify a set of dispatchers as
> follows:
[snip]
> # I will document it in rubyforge's wiki later.

Long time but I wrote a little doc about dispatchers in rubyforge's wiki.

AP4R Wiki: Dispatchers 
==== 
    1. Default configuration
    2. List of dispatchers
        2.1. HTTP
        2.2. SOAP
        2.3. XML-RPC
        2.4. druby
    3. Message modification
        3.1. URL rewrite
    4. Multiple dispatchers
    5. How to add a custom dispatcher
    6. References
====  http://ap4r.rubyforge.org/wiki/wiki.pl?Dispatchers

HTH
shino