oodt-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Barkstrom <brbarkst...@gmail.com>
Subject Re: Multiple Processing Paradigms at Once
Date Wed, 06 Aug 2014 15:52:45 GMT
I don't have a deep enough insight into the OODT architecture
to know for sure how that would work.  From an architectural
point of view, it would be useful to have UML synchronization
diagrams that show the threads of computation and the message
passing that you need to undertake for this work.  It's a familiar
problem in the embedded systems world (avionics, multi-computer
automobile control systems with 80 computers per car).  A good
reference on this kind of design work is Bruce Douglass' "Real-Time
UML".  It might also be useful to find a copy of Klein, et al., 1993:
"A Practicioner's Handbook for Real-Time Analysis: Guide to
Rate Monotonic Analysis for Real-Time Systems", Kluwer.
It isn't clear whether you want to do the design for the hard
real-time kind of system (where the system fails if messages
aren't received within a set priority) or less stringent kinds of
systems.  Exception handling gets to be a really "interesting"
part of these kinds of designs.

Bruce B.


On Wed, Aug 6, 2014 at 11:29 AM, Michael Starch <starchmd@umich.edu> wrote:

> All,
>
> I am working on upgrading OODT to allow it to process streaming data,
> alongside traditional non-streaming jobs.  This means that some jobs need
> to be run by the resource manager, and other jobs need to be submitted to
> the stream-processing.  Therefore, processing needs to be forked or
> multiplexed at some point in the life-cycle.
>
> There are two places where this can be done: workflow manager runners, and
> the resource manager.  Currently, I am  working on building workflow
> runners, and doing the job-multiplexing there because this cuts out one
> superfluous step for the streaming jobs (namely going to the resource
> manager before being routed).
>
> Are there any comments on this approach or does this approach make sense?
>
> -Michael Starch
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message