Help with async xmlrpc design

[Amit Khemka]

On 8/17/06, David Hirschfield <davidh at ilm.com> wrote:
> I have an xmlrpc client/server system that works fine, but I want to
> improve performance on the client side.
>
> Right now the system operates like this:
>
> client makes request from server (by calling server.request() via xml-rpc)
> server places "request" on queue and returns a unique ID to the calling
> client
> client repeatedly asks server if the request with the given ID is
> complete via server.isComplete(<id>)
> server eventually completes processing request
> client eventually gets an affirmative from server.isComplete(<id>) and then
> client pulls results from server via server.fetchResults(<id>)
>
> originally the client only made one request at a time, and each one was
> processed and results fetched in order.
>
> I want to change this so that the client can send multiple requests to
> the server and have them processed in the background.
> There are a lot of different approaches to that process, and I'd like
> advice on the best way to go about it.
>
> I could simply place the request checking and results fetching into a
> thread or thread-pool so that the client can submit requests to some
> kind of queue and the thread will handle submitting the requests from
> that queue, checking for completion and fetching results.
>
> Unfortunately, that would mean lots of calls to the server asking if
> each of the requests is complete yet (if I submit 100 requests, I'll be
> repeatedly making 100 "are you done yet?" calls). I want to avoid that,
> so I thought there would be some way to submit the request and then hold
> open the connection to the server and wait on the completion, but still
> allow the server to do work.
>
> Any advice on how to avoid polling the server over and over for request
> completion, but also allowing the client to submit multiple requests
> without waiting for each one to finish before submitting the next?

One obvious improvement over your current scheme would be that instead
of polling server for each request submitted, have a unified polling
mechanism wherein server returns a list of "ids" of all processed
request.


But as you too mentioned polling is "often" not the best way, You may try say:

1. Upon submitting a request, client-server agree upon a port on which
client will listen for the results.
2. Registering a callback function.
 (Googling would point to more elaborate discussions on pros and cons )

cheers,
amit.


----
Amit Khemka -- onyomo.com
Home Page: www.cse.iitd.ernet.in/~csd00377
Endless the world's turn, endless the sun's Spinning, Endless the quest;
I turn again, back to my own beginning, And here, find rest.