On 10-11-26 03:16 PM, Jan Wieck wrote:
> On 11/17/2010 5:06 PM, Christopher Browne wrote:
>> A thing that several of us have been ruminating over for a while is the
>> problem that people get confused about how you submit Slonik scripts,
>> you may have some actions that require waits.
>
> One major problem with automatic waiting for events is that it is
> extremely context sensitive to wait at all.
>
> One cannot wait inside of a TRY block. The events aren't committed yet,
> so they cannot propagate.
>
> One needs to be careful not to wait if the current path configuration is
> incomplete. You should for example never wait for the FIRST store path
> ... you'd wait forever.
>
> This all basically exposes that slonik has insufficient knowledge about
> the overall cluster configuration and healthiness. It basically fires
> off "commands" blindly. I've long been thinking that slonik itself needs
> a major overhaul. My recent experiences with the Mozilla Rhino
> JavaScript engine (Steve and I developed a cluster test framework using
> it) makes me think that actually creating a complete new slonik from
> scratch won't be too bad of an idea.

What would you want to change in slonik (from the users point of view) 
if you were doing that?

When I was developing tests for the framework I spent countless hours 
debugging tests were the problem ended up being a missing or an extra 
wait for (or one against the wrong node). Expecting the average DBA to 
figure this stuff out isn't nice.   Slonik should be able to figure out 
if paths exist to the required nodes and other dependencies on the 
configuration.  I think slonik should check as many things as we can 
make and give the user useful error messages instead of 'waiting for ever'

I agree with Vick that a Java dependency for slony would be a bad idea.


>
>
> Jan
>