Re: [Smartfrog-support] Termination due to slow start-up.

Sorry, posting to the list instead.

On 14/02/2008, Steve Loughran <[email protected]> wrote:
 > Ismael Juma wrote:
 >  > Hi Julio,
 >  >
 >  > Thank you for the reply.
 >  >
 >  > On Wed, 2008-02-13 at 10:23 +0000, Guijarro, Julio wrote:
 >  >> Hi Ismael,
 >  >>
 >  >> sfPing starts once the component is deployed and therefore it will
 >  >> check if the component is alive during sfDeploy and sfStart as well.
 >  >> This means that the components should not block on the sfDeploy and
 >  >> sfStart methods.
 >  >
 >  > I see.
 >  >
 >  >> The general rule is that any long operation (ex. starting a DB)
 >  >> started inside those methods should be processed in a separate thread
 >  >> to avoid liveness failures.
 >  >
 >  > Makes sense.
 >  >
 >  >> To test if this is your case you can make liveness 0 (liveness =
 >  >> disabled)
 >  >>
 >  >>   org.smartfrog.sfcore.processcompound.sfLivenessDelay=0
 >  >>
 >  >> and see if your example now works.
 >  >
 >  > It does indeed work.
 >  >
 >  >> If this solves your problem please file a bug against the Jetty
 >  >> component and we will fix it for next release.
 >  >
 >  > Done[1].
 >
 >
 > This could be due to a threading problem (I'm not starting one), or it
 >  could be down to a thread being started, but the underlying components
 >  taking longer to go live than expected. For example, the jetty servlet
 >  code expects that if there is
 >  some jetty class, then it had better be running:
 >
 >      public void ping() throws SmartFrogLivenessException, RemoteException {
 >          if (holder == null || !holder.isStarted()) {
 >              throw new SmartFrogLivenessException("Servlet " +
 >                      name +
 >                      " is not running under" + getAbsolutePath());
 >          }
 >      }
 >
 >
 >
 >  which component is causing the trouble?
 >
 >  2. what do people think we should do here? Not do any liveness checks
 >  and rely on web page livenesspage tests? Tests you'd have to delay with
 >  a Sleep{ } component so they don't fail early either.


I like the liveness checks myself, but as a suggestion:, is there any
 reason for people to use Sleep in the manner I think you're
 suggesting? How about a component similar to
 java.util.concurrent.CountdownLatch, which would block doing the page
 liveness tests until the system is in an appropriate state?

 Cheers,


 James


 >
 >  3. There is a slowstart component in the workflow, though I see that it
 >  is not declared in any .sf file, and hence won't have any tests/docs
 >  either. It explicitly delays passing down liveness tests until after a
 >  prespecified delay
 >
 >  start extends SlowStart {
 >    delay 5000;
 >    action JettyServer;
 >  }
 >
 >
 >
 >  --
 >  -----------------------
 >  Hewlett-Packard Limited
 >  Registered Office: Cain Road, Bracknell, Berks RG12 1HN
 >  Registered No: 690597 England
 >
 >
 >  -------------------------------------------------------------------------
 >  This SF.net email is sponsored by: Microsoft
 >  Defy all challenges. Microsoft(R) Visual Studio 2008.
 >  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
 >  _______________________________________________
 >  Smartfrog-support mailing list
 >  Smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
 >  https://lists.sourceforge.net/lists/listinfo/smartfrog-support
 >

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/