river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Bug nominations
Date Thu, 10 Feb 2011 17:10:48 GMT
"Many times better hardware is a better choice."

That depends on how you weight the pros and cons of course....

Many enterprises go with "better hardware as a better choice" and ultimately
still suffer horrendous complexity, uncontrollable/difficult to manage
failures, high operational costs, cheaper developers (ironically they
produce less stuff and it's more likely to be anything other than what the
customer desires) etc.

Some enterprises go with cheap hardware, "guesses" as you call them, or
indeed tradeoffs of CAP theorem as I prefer to call them. They tend to have
fewer and better developers and potential (not always realised) for
"operational sanity" (well understood, simple processes for failure
handling, no special hardware arrangements etc).

"Better choice" then, for me at least, is more like "more suited to the
average enterprise environment where there isn't particularly good
understanding of the consequences of that choice and little genuine care for
decent product". At the risk of offending people it's the equivalent of
putting Windows on a PC and tolerating the endless reboots etc. I prefer OS
X or some other variety of UNIX.

An example:

Everyone loves Oracle, they build clusters of high quality hardware, have
asynchronous replication to a DR site and write their software as if the
database is always present. They often place all their code on top of a
single database. The day comes when that database fails (dies, exhibits a
bug, network fails, performance goes through the floot, yes these things all
happen and more often than people would like to believe) and the entire
business stops. Oh they recover eventually, probably lose some transactions
along the way (because they didn't understand what asynchronous replication
does), suffer a myriad of deployment and recommissioning issues but they
stagger on complaining as they go and burning huge quantities of cash just
to keep themselves alive.

This is a whole big topic, I could go on for hours, I'm sure others can too
and I'm sure we'll have many differing opinions but the overall challenge is
the same:

(1) What kind of systems do we want to build with Jini?
(2) What kind of users do we want using Jini?
(3) What kinds of stuff do we need to build given (1) and (2).

I have a particular (obvious?) bias, I believe Jini might satisfy that
desire equally I could imagine lots of people would like to make Jini the
same old, same old that Oracle, SpringSource and such provide. The further
we are from the former and the closer we are to the latter, the less I'll
have any interest because it's all been done before.

On 10 February 2011 16:49, Gregg Wonderly <greggwon@gmail.com> wrote:

> In a recent project, I built a distributed postgres database using
> transactions and a rather interesting InvocationHandler implementation that
> allows a mesh network to exist between all participants so that everyone
> sees every change.   From a participants perspective, there are zero or more
> client displays that show and dynamically update the display of data, there
> are database host, and there are external servers that use the API calls to
> change incore memory versions of the persistent data.
> The transaction rate, because all participants are on a local network, is
> quite performant.  But, there are some issues with how the transaction
> manager failures work out (including some of the bugs Patricia has found
> that we had not managed to see the cause of) that make it a bit fragile for
> continued use.
> I'd personally have a great desire to have TransactionManager be a focus of
> some effort to try and finish getting its behavior to be dependable and
> consistent for a single process service.
> When you go to have a distributed view of the same data across multiple
> systems, you get all the problems of partial failure being an impediment to
> successful operations on each transaction.   Dan Creswell and I have had
> many a discussion about how it is often easier to build a "better piece of
> hardware" than to "distribute a software system".   Many times better
> hardware is a better choice.
> When you look at Hadoop and Googles use of "cheap hardware", you can see
> how the line can be drawn in the sand at some point to just provide limited
> functionality and use "guesses" to move forward.
> Gregg Wonderly
> On 2/9/2011 5:28 PM, Jeff Ramsdale wrote:
>> +1. The lack of partitioning and fault-tolerance is exactly what's
>> keeping my current employer from using Outrigger, though they'd love
>> to. They do use Jini, though, so they'd be an easy sell if such a
>> thing were available.
>> -jeff
>> On Wed, Feb 9, 2011 at 3:13 PM, Patricia Shanahan<pats@acm.org>  wrote:
>>  What do others think of this general idea, as a development direction for
>>> River?

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