[omniORB] [Q]report server architecture with omniOrb

[V S P]

Thank you

If the 
ReportGenerator ::StartProcessingRequest

returns back 'true', what mechanism should there be
to allow the same ReportGenerator server instance to beging
the several hours work on the report?

In otherwords, can I somehow reuse pre-spawned threads within 
the report generator (after replying 'true') and ask them: now start
processing this request.

For example, in older applications I worked with -- there was
a simple thread-safe queue of tasks for the worker threads.

So what I thought, I need, is a way, may be,
for the ReportGenerator ::StartProcessingRequest to post a task
onto the internal OmniOrb queue (if such a thing exists)
such that one thread unlocks and starts processing the task.

or otherwise, how would I commence the processing such that
the 'response' -- 'yes I will take on the work' --  is decoupled
from the actual work.


thank you again,
Vlad





On Thu, 05 Feb 2009 08:10:44 +0100, "Martin Trappel" <0xCDCDCDCD at gmx.at>
said:
> V S P wrote:
> > Hi,
> > I am new to the list.
> > Currently designing a somewhat simple (but distributed) reporting server
> > that will be using postegres and files joining them together to create
> > reports.
> > 
> > The way the system would work is there is a table called request_queue
> > an entry there would indicate a type of report to run and the status of
> > the entry (submitted, executed, errored, inprogress).
> > 
> > Reports can take several hours to run, so the 'report servers'
> > have to be asynchronious.
> > 
> > I was thinking I coud use omniOrb to implement the 'distribution'
> > underpinning. However I am having difficulties invisioning how it can be
> > done.
> > 
> > a) assuming that I have some kind of a 'dispatcher' client that reads
> > the data from the queue table, then it needs to figure out which one of
> > the report serveres is not busy -- and send the request to that one.
> > 
> > b) the server would take the request, will say 'thank you' and work it
> > on it for a couple of hours, and then update the status of the queue
> > entry as 'executed'.
> > 
> 
> Since both the Servers and the Dispatcher-Client need to talk to the 
> postgre Database, you could just leave CORBA out completely and let them 
> talk via the database ...
> 
> > I thought I would need Naming Service and notification service for this,
> > however, my undestanding is that Notification service is not really
> > supported and certainly not working in Windows with VC++ 9
> > 
> > Wanted to ask if anybody has recommendation of what OmniOrb features I
> > need to look for/use for the above (or if there are better alternatives)
> > 
> 
> I'm not sure you even need the Naming Service.
> 
> // Multiple Instances on multiple machines:
> interface ReportGenerator {
>    // return true on OK, false on currently busy
>    // ReportDispatcher can call al registered servers until one returns
>    true
>    bool StartProcessingRequest(in request_id id);
> }
> 
> // Dispatcher Service, starting the report generation.
> // Servers look it up via corbaloc.
> interface ReportDispatcher {
>    void RegisterGenerator(in ReportGenerator r);
>    void UnregisterGenerator(in ReportGenerator r);
> 
>    void RequestFinished(in request_id id);
> }
> 
> 
> br,
> Martin
-- 
  V S P
  toreason at fastmail.fm

-- 
http://www.fastmail.fm - Does exactly what it says on the tin