On Dec 1, 2007, at 12:54 AM, Robert Hodges wrote:
...
BTW, what are you using Sequoia for?
Thanks!
Robert
Thank you for fixing the PingResponder thread shutdown thread bug.
Can't wait to upgrade.
To answer your question, we're using Sequoia to split a very large
database into many smaller ones, spread over hundreds of machines,
with multiple copies of each slice for fault tolerance. We embedded
Sequoia into our application, instead of running it the normal,
standalone way, since we needed extra functionality and only wanted
to run one JVM. We run one JVM per machine, one controller per JVM,
and maybe 10 virtual databases per each controller, each vdb with a
local embedded H2 database backend.
Things we added:
* start / stop servers in any order
* automatically handle unclean shutdown
* automatically replicate if a database finds it has the only copy on
the network
* encryption of databases, backups, and JGroups communication channels
* automatic scheduling of backups
* plug in to our own monitoring system
We also wanted to hide the Sequoia functionality we didn't need, to
reduce complexity. We only use RAIDb-1 in a specific configuration.
Difficulties we encountered:
* getting our unit tests to work. Sequoia doesn't play well with
others if you embed it:
** starting/stopping/restarting a controller is difficult (we needed
numerous hacks to work around problems like the PingResponder thread
not going away and the inability to restart the MBeanServer)
** difficult to run >1 controller in 1 VM, to be able to test that
statements are indeed distributed correctly. We'd never run like
this, but we need to test our code that uses Sequoia.
** testing backup transfers in 1 VM. Had to change Backuper logic to
store and use relative paths.
* development:
** lack of clarity on which functions are appropriate for me to use
(inconsistent public/(package) scoping led me down possibly incorrect
paths)
** lots of trial and error figuring out the ordering for setup
operations (we're not using the XML parser)
** concern about being tied to a specific version of Sequoia - will
all of my workarounds still work if I upgrade
** old dependency jars. We needed features in JGroups 2.5, which
didn't work with Sequoia due to SEQUENCER protocol being incompatible
with the thread model changes in 2.5. (fixed in my code and upcoming
JGroups 2.6 release)
** hostname / jmxname problems (must specify ipAddress="0.0.0.0" to
listen on all interfaces, but then jmx names won't be unique. have
to call controller.setIpAddress AFTER controller.launch - ugly hack)
** ... and other problems we've had to work around. I'll try to add
them to JIRA.
Things I'd suggest:
* Try starting, stopping, and restarting a Sequoia controller in one
VM. Fix the things that make this not work out of the box. Try two
controllers, too.
* Unit tests. I'd feel much more comfortable using Sequoia if it had
unit tests with good code coverage. (plus that would have given me
hints on how to use the objects)
Hopefully this is useful. Looking forward to the upcoming release!
-Chris
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
