I have no problem with this as a base for discussing the long term issues.
In the short term, there is another Jira I need to write - reporting a
bug in Outrigger. I got into this because of an intermittent QA test
failure on Hudson. That needs to be fixed, either by finding out what is
specifically wrong in the existing FastList implementation, other than
being too complicated, or writing a new, simpler, more maintainable
FastList.
Patricia
Tom Hobbs wrote:
I've taken the liberty of creating a new Jira for the refactoring of
FastList in the Outrigger internals.
https://issues.apache.org/jira/browse/RIVER-386
Sorry is that's presumptuous or if the wording of ticket is wrong. I
thought it'd be good to start getting something a bit more structured
down. Particularly if we can get the details of the kinds of numbers
that Mike is talking about.
Personally, I think that Mike's (and others) comments are exactly what
this dev community needs to see. Any implementation decision we make
(particular when refactoring existing functionality) needs to have (at
least) an eye on the needs of our users.
On Thu, Dec 16, 2010 at 4:01 PM, Patricia Shanahan <p...@acm.org> wrote:
Mike McGrady wrote:
Intense network systems like our clients cannot work with database
calls. They are too slow and do not scale. They either reach a cost
or a performance ceiling.
I feel we are mixing requirements and implementation. Response time,
throughput, ACID properties and the like are requirements. What Outrigger
uses as persistent storage for tuple space is implementation.
I would like to get more data on your performance requirements - specifics
about e.g. x% of JavaSpace reads under these conditions must complete within
y seconds.
The most useful and specific way of presenting requirements would be a
scalable benchmark - something where we can simulate a larger number of
machines doing real work by having a smaller number dedicated to driving
transactions at a single JavaSpace and measuring the results.
Measurements from a small to medium sized environment would be useful input
for estimating performance at higher loads. Without that sort of data, I
cannot even guess whether an achievable Outrigger implementation will be
able to meet all your requirements.
Patricia
