Re: sfStart() timeout

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)).

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.

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

-----Original Message-----
From: smartfrog-support-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-support-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
Dominik Pospisil
Sent: 28 November 2006 09:56
To: smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: [Smartfrog-support] sfStart() timeout

Hello there!

I am trying to write a smartfrog component which's start can take
ralativelly long time (even minutes). The problem is following. Should I
run component startup in a new thread and exit sfStart() immidiatelly or
should I block
sfStart() until component starts up?

According to docs, when a compoent leave sfStart(), SF assumes that
component is running and ready. But If I block sfStart() until component
is ready, I receive liveness check errors.

If I do not block sfStart(), dependant components will fail to start,
because component is not ready yet.

Did I missed something? Is there another solution than increasing
liveness checking period?

Thanks,

- Dominik

------------------------------------------------------------------------
-
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=DEVDE
V
_______________________________________________
Smartfrog-support mailing list
Smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/smartfrog-support

-------------------------------------------------------------------------
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