river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: TaskManager requirements
Date Tue, 13 Jul 2010 18:01:18 GMT

On Tue, 2010-07-13 at 13:03, Patricia Shanahan wrote:

> Several customers have, over the years, beat into my head the 
> understanding that a crash is better than a wrong answer. That is 
> particularly the case for a redundant service.
> 

A koan to lead you to Jini zen: "If a service crashes, but its client
does not get a reply, did it really crash?"

Or, as I've said in other places, "It's a network, deal with it".  Jini
is all about graceful recovery, not crash prevention. Fallacy 1 - "The
network is reliable".

> Meanwhile, I have a question about a related issue. If a Task runAfter 
> method throws anything it is logged and TaskManager acts as though 
> runAfter had returned false, indicating no dependencies.
> 
> That is the high performance but high functional risk option. It may 
> create low frequency, hard to reproduce, timing bugs, my least favorite 
> type of bug.
> 
> An alternative would be to make the task wait for completion of all 
> older tasks. That is worse performance but much safer.
> 
> Thoughts?
> 

Not sure.  Might there be a deadlock issue?  Probably not, but you'd
have to take a look at TaskManager and its dependents.

It's probably worth noting that since it's part of "com.sun.jini", one
could likely view TaskManager as an implementation detail for the other
com.sun.jini classes (e.g. the Reggie implementations).  In other words,
you don't need to design for general functionality, just usage scenarios
within River itself.

> Patricia

Cheers,

Greg.

-- 
Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.
http://stratuscom.com


Mime
View raw message