Thanks Dawid, I'd appreciate it if you have time.
checkout https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk
then cd to trunk
$ vi build.properties
append the line:
run.tests=com/sun/jini/test/impl/outrigger/matching/StressTestInterleaved.td
Thanks for the feedback, that's just the sort of thing we need on river dev.
Considering a persistent Outrigger for a moment, would a JDO store that
could use Cassandra, Google Big Table, Amazon S3, MongoDB, Google
Storage et al be more interesting?
These data stores will have their cache, storage and retrieval
algorithms well sorted, there's the matter of optimisation of course,
one of the problems we have with River is the lack of access to hardware
suitable for tuning.
Outrigger could become a sub project if there was enough interest.
Regards,
Peter.
On 14/01/2014 1:29 AM, Dawid Loubser wrote:
Hi,
I might be able to help. How do I run these tests (what branch do I
check out, etc)?
For the record, an *in-memory* Outrigger has always scaled very well
for us.
However, *persistent* outrigger with SnapLogStore has caused us major
problems in the past, causing us to switch to Blitz.
With around 10,000 entries (approacing a total size of 3GB, these were
very very complex object graphs) it rapidly ground to a halt, and
became irrecoverable.
There were probably 200 readers / writers. This was on some pretty
decent hardware, and with this same load, Blitz has no problems
whatsoever.
kind regards,
Dawid
Op Di, 2014-01-14 om 00:24 +1000 skryf Peter Firmstone:
Hmm, 10,000 entries, 400 readers and 250 writers don't appear to be a
problem either.
Anyone have some really decent hardware to give Outrigger a proper workout?
Cheers,
Peter.