Re: sfStart() timeout

Hello again!

Thank you very much for your comments!

Well, I have to say that it is exactly what I was afraid of :) It seems to me 
too overcomplicated for something as simple as having one component waiting 
until another component is ready. I would like to have an option to start the 
component in separate thread asynchronously and than notify smartfrog 
framework when the component is ready.

But please, do not take my opinions too seriously since I am quite new here 
and I will get used to SF soon :)

Thank you again,
Dominik

Steve Loughran wrote:
> My recommendation would be to start the work in a separate thread, and
> respond fairly quickly. This means that smartfrog can move everything
> into the started state fairly rapidly.

I still do not know why. Where is the point of having all SF-components in 
started state rapidly while underlying services are not ready yet? I think 
that SF-component state should correspond to service state.

> However, your component's liveness checking code needs to be designed to
> respond to a liveness check while the system is still coming up and not
> fail.
>
> It leaves the problem of how do you block other parts of the system
> until what you are starting comes up. Which, in the case of something

Exactly. I think that component dependency should be provided by the framework 
and not to be reimplemented again.

> big like a Xen linux image with a database on top can take a while.
> What I've done with that in the past is add new components whose role is
> to block waiting for the visible state of something to change. For
> example, there is a WaitForPage component in the www module that deploys
> a thread that waits for a web page to be readable with an error code in
> range; it will terminate when the page is successfully retrieved. You
> can then use a workflow where you have a sequence of things that block
> until the blocking component is ready.
>
>
> system extends Parallel {
>
>        appserver extends JBossJVM {
>        }
>
>
>        deployment extends Sequence {
>          probe extends SpinUntilHappy {
>          }
>
>         tests extends Junit {
>           ...
>         }
>       }
>
> }
>
>
> What I havent done yet is factor out the test, to have a specific
> Condition interface that anything can implement to be a condition; we
> could have different components to act on these (if/while/waitfor, etc).
> This would tie in well with what I am implementing w.r.t test
> components. I have a (very unstable) test compound whose aim is to
> deploy something, run some tests and then clean up. This stuff is very
> raw right now, as I'm just starting to use it to test the JDBC components:
>
> TableManipulationTest extends TestCompound {
>
>      action extends Compound {
>          db extends TestDB;
>      }
>
>      tests extends Sequence {
>
>          -- extends CreateUser {
>            database LAZY action:db;
>            username "newuser";
>            password "secret";
>          }
>
>          -- extends CreateEventsTable {
>            database LAZY action:db;
>          }
>
>          -- extends SelectionWorkflow {
>            database LAZY action:db;
>            sqlCommands [
>              "SELECT * from events"
>              ];
>          }
>
>          -- extends DropTable {
>              database LAZY action:db;
>              table "events";
>          }
>      }
>    }
>
> Here it deploys the action; once that is started it runs the tests.  For
> that to work against a slow-to-start system I need to block until the
> database is up. While I could put a Block-until-socket-ready component
> into the sequence, having a separate Condition clause would be good as
> the test results would be more meaningful. The test run could look more
> like :
>
>
>
>
> TableManipulationTest extends TestCompound {
>
>      deployTimeout 60000;
>      probeTimeout 60000;
>
>      action extends Compound {
>          db extends TestDB;
>      }
>
>      probe extends SocketOpen {
>        port action:db:port;
>      }
>
>      tests extends Sequence {
>
>          -- extends CreateUser {
>            database LAZY action:db;
>            username "newuser";
>            password "secret";
>          }
>
>          -- extends CreateEventsTable {
>            database LAZY action:db;
>          }
>
>          -- extends SelectionWorkflow {
>            database LAZY action:db;
>            sqlCommands [
>              "SELECT * from events"
>              ];
>          }
>
>          -- extends DropTable {
>              database LAZY action:db;
>              table "events";
>          }
>      }
>    }
>
>
> I'd then have the test compound would block until the probe was happy or
> a timeout kicked in.
>
> what do you (and the others) think?
>
> -steve


Patrick wrote:
> Our recommended practice is not to block sfStart, but to do things in a
> separate thread. The lifecycle is about getting components up and
> running, and to be able to respond to requests (as a component) not
> necessarily as finished piece of system configuration. It is very
> convenient when the two match, but this is not always possible.
> 
> If you really do want to stall the sfStart, you can certainly slow down
> liveness checking, or allow more missed hearbeats, or switch it off
> compeltely. There are a number of attributes that control this
> (sfLivenessFactor(how many can I miss) and sfLivenessDelay(how often)).

That is what I do not want to do. Once the components are started I want to 
have liveness checking enabled.

> If you do not want to stall the start thread, then there are a number of
> techniques we use - just none quite as convenient. 
> 
> One is to provide an attribute (a boolean say) when the system doess
> finally comes up to its final state. Requests for this attribute can
> either return false, or a resolution exception, or you can catch the
> resolution of that attribute and stall it until the system is
> configured. However this can cause the deployment thread in another
> component to stall if you resolve it during its startup.

This is actually the case. If I do not stall that component I will have to 
stall another.

> Equivalently, you can provide an API which allows another component to
> inspect the status.
> 
> However both of these require that the rest of the system deployment is
> synchronized using these mechanisms and that can mean more programming.
> 
> So another way we provide is the workflow components - especially
> sequence in this case - which allows more control of the phasing of the
> component lifecycles. There is a document the set that covers this. If
> you have any diffilculty using this, or questions as to its
> applicability, please let us know.
> 
> Patrick

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV