[wildfly-dev] Graceful startup

[Stuart Douglas]

At the moment I am leaning towards holding request rather than rejecting.
If the user really wants reject behavior they can uses suspend/resume to
achieve this.

Stuart

On Fri, 22 Apr 2016 at 12:00 gaoyonglu at 126.com <gaoyonglu at 126.com> wrote:

> One thing I am not really sure about is if we need a configuration
> > switch for hold/reject behavior
>
> I think use reject is better. The weblogic server start graceful use
> reject and if use hold option we must set queue to hold request.
>
> I  very much looking forward to this feature
> ------------------------------
> gaoyonglu at 126.com
>
> *From:* wildfly-dev-request <wildfly-dev-request at lists.jboss.org>
> *Date:* 2016-04-22 07:00
> *To:* wildfly-dev <wildfly-dev at lists.jboss.org>
> *Subject:* wildfly-dev Digest, Vol 37, Issue 9
> Send wildfly-dev mailing list submissions to
> wildfly-dev at lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> or, via email, send a message with subject or body 'help' to
> wildfly-dev-request at lists.jboss.org
>
> You can reach the person managing the list at
> wildfly-dev-owner at lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of wildfly-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Graceful startup (David M. Lloyd)
>    2. question on jboss-app_7_0.xsd intermingling jee versions
>       (Rob Stryker)
>    3. Re: question on jboss-app_7_0.xsd intermingling jee versions
>       (Rob Stryker)
>    4. Re: Graceful startup (Brian Stansberry)
>    5. Re: Graceful startup (John Doyle)
>    6. Re: Graceful startup (Brian Stansberry)
>    7. Re: Graceful startup (Stuart Douglas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 21 Apr 2016 06:50:47 -0500
> From: "David M. Lloyd" <david.lloyd at redhat.com>
> Subject: Re: [wildfly-dev] Graceful startup
> To: wildfly-dev at lists.jboss.org
> Message-ID: <5718BE97.9010405 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 04/20/2016 09:05 PM, Stuart Douglas wrote:
> > Hi,
> >
> > I have come across a few bug reports [1][2] (and a feature request from
> > the Swarm team) recently that are essentially caused by an application
> > being accessed before it is fully deployed. Basically even though we
> > have service dependencies that make sure individual components
> > dependencies are up, once a request has been accepted it can potentially
> > programmatically access other parts of the deployment that are not up
> > yet (basically the same problem we have with graceful shutdown, but in
> > reverse).
> >
> > I propose we solve this using a 'graceful startup' mechanism, that holds
> > or rejects new requests until a server or deployment is fully started.
> > The specifics of how this would work are:
> >
> > - If the server is booting all external requests will be held or
> > rejected until the the boot process is complete
> > - When deploying a new deployment all requests for that deployment will
> > be held or rejected until MSC has attained stability
> >
> > This would be implemented for the following endpoints/subsystems:
> >
> > - Undertow will hold requests until the deployment is done (so if you
> > try and load a page while deployment is happening it could be a bit of a
> > wait)
> > - Remote EJB will hold requests until deployment is done
> > - mod_cluster will not send availability messages until deployment is
> done
> > - JMS will delay message delivery until deployment is done
> > - EJB persistent timers will not fire until deployment is done
> > - Possibly some other cases I can't think of right now
> >
> > One thing I am not really sure about is if we need a configuration
> > switch for hold/reject behavior. e.g. for Undertow the request holding
> > behavior is very developer friendly, as it means they can just hit
> > refresh in their browser and as soon as the redeployment is done the
> > page will display, however I am worried that it might not be ideal for
> > load balancers that may prefer a quick error response that could then be
> > attempted on another node (although if mod_cluster is not sending out
> > availability till the deployment is 100% complete this may not be a big
> > deal).
>
> I think load balancers should not have a server that is being started up
> in the rotation anyway; this already probably doesn't work great today.
>
> I like the idea overall.
>
> --
> - DML
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 21 Apr 2016 12:08:05 -0400
> From: Rob Stryker <rstryker at redhat.com>
> Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee
> versions
> To: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
> Message-ID: <5718FAE5.2020307 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi guys:
>
> I recently opened https://issues.jboss.org/browse/JBMETA-394 because it
> seems our application schema are intermingling jee versions between ee6
> and ee7,  and it's causing problems for our eclipse validators.
>
> Who's in charge of these schema, specifically? Who would be the right
> person to ping to get it fixed?
>
> - Rob Stryker
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 21 Apr 2016 12:13:51 -0400
> From: Rob Stryker <rstryker at redhat.com>
> Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd intermingling
> jee versions
> To: wildfly-dev at lists.jboss.org
> Message-ID: <5718FC3F.4020300 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> Ok, seems I missed some responses before.
>
> > Max Anderson wrote:   Rob - is the error you see on the
> jboss-application.xml you wrote or in  the included xsd ?
>
> I opened https://issues.jboss.org/browse/JBMETA-394  for a more clear
> explanation as to the specific error. The error is in a user's
> jboss-application.xml.
>
> > Marek wrote:  I guess you mixed Java EE 6 with JBoss AS 7 versions here.
>
> I'll try to find out where the example is coming from. If it's from one
> of our published examples, then I would guess it needs to be fixed
> there. Looking at the released versions of jboss-app_x_y.xsd,  it would
> seem Marek is probably right and the versions there match the jboss/wf
> releases, and not the ee version.
>
> I'll dig deeper. Thanks.
>
> On 04/21/2016 12:08 PM, Rob Stryker wrote:
> > Hi guys:
> >
> > I recently opened https://issues.jboss.org/browse/JBMETA-394 because it
> > seems our application schema are intermingling jee versions between ee6
> > and ee7,  and it's causing problems for our eclipse validators.
> >
> > Who's in charge of these schema, specifically? Who would be the right
> > person to ping to get it fixed?
> >
> > - Rob Stryker
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 21 Apr 2016 13:44:48 -0500
> From: Brian Stansberry <brian.stansberry at redhat.com>
> Subject: Re: [wildfly-dev] Graceful startup
> To: wildfly-dev at lists.jboss.org
> Message-ID: <57191FA0.9070800 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 4/20/16 9:05 PM, Stuart Douglas wrote:
> > Hi,
> >
> > I have come across a few bug reports [1][2] (and a feature request from
> > the Swarm team) recently that are essentially caused by an application
> > being accessed before it is fully deployed. Basically even though we
> > have service dependencies that make sure individual components
> > dependencies are up, once a request has been accepted it can potentially
> > programmatically access other parts of the deployment that are not up
> > yet (basically the same problem we have with graceful shutdown, but in
> > reverse).
> >
> > I propose we solve this using a 'graceful startup' mechanism, that holds
> > or rejects new requests until a server or deployment is fully started.
> > The specifics of how this would work are:
> >
> > - If the server is booting all external requests will be held or
> > rejected until the the boot process is complete
> > - When deploying a new deployment all requests for that deployment will
> > be held or rejected until MSC has attained stability
> >
> > This would be implemented for the following endpoints/subsystems:
> >
> > - Undertow will hold requests until the deployment is done (so if you
> > try and load a page while deployment is happening it could be a bit of a
> > wait)
> > - Remote EJB will hold requests until deployment is done
> > - mod_cluster will not send availability messages until deployment is
> done
>
> Isn't this what mod_cluster does on a per-deployment basis anyway? The
> basic idea of mod_cluster is the LB isn't notified the context is
> available on a backend server until it's....available.
>
> > - JMS will delay message delivery until deployment is done
> > - EJB persistent timers will not fire until deployment is done
> > - Possibly some other cases I can't think of right now
> >
> > One thing I am not really sure about is if we need a configuration
> > switch for hold/reject behavior. e.g. for Undertow the request holding
> > behavior is very developer friendly, as it means they can just hit
> > refresh in their browser and as soon as the redeployment is done the
> > page will display, however I am worried that it might not be ideal for
> > load balancers that may prefer a quick error response that could then be
> > attempted on another node (although if mod_cluster is not sending out
> > availability till the deployment is 100% complete this may not be a big
> > deal).
> >
> > If you want to see this in action I have a very simple PR at [3] that
> > enables this for Undertow at server boot.
> >
> > Thoughts?
> >
> > Stuart
> >
> > [1] https://issues.jboss.org/browse/WFLY-6402
> > [2] https://issues.jboss.org/browse/JBEAP-867
> > [3] https://github.com/wildfly/wildfly/pull/8858
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 21 Apr 2016 15:07:18 -0400
> From: John Doyle <jdoyle at redhat.com>
> Subject: Re: [wildfly-dev] Graceful startup
> To: Brian Stansberry <brian.stansberry at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Message-ID:
> <CAKSM3ocU+B0gXue4fu6JUZ=wA_Ov9F3kPRhEeAFU-OAO5GgNNQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
> > On 4/20/16 9:05 PM, Stuart Douglas wrote:
> >> Hi,
> >>
> >> I have come across a few bug reports [1][2] (and a feature request from
> >> the Swarm team) recently that are essentially caused by an application
> >> being accessed before it is fully deployed. Basically even though we
> >> have service dependencies that make sure individual components
> >> dependencies are up, once a request has been accepted it can potentially
> >> programmatically access other parts of the deployment that are not up
> >> yet (basically the same problem we have with graceful shutdown, but in
> >> reverse).
> >>
> >> I propose we solve this using a 'graceful startup' mechanism, that holds
> >> or rejects new requests until a server or deployment is fully started.
> >> The specifics of how this would work are:
> >>
> >> - If the server is booting all external requests will be held or
> >> rejected until the the boot process is complete
> >> - When deploying a new deployment all requests for that deployment will
> >> be held or rejected until MSC has attained stability
> >>
> >> This would be implemented for the following endpoints/subsystems:
> >>
> >> - Undertow will hold requests until the deployment is done (so if you
> >> try and load a page while deployment is happening it could be a bit of a
> >> wait)
> >> - Remote EJB will hold requests until deployment is done
> >> - mod_cluster will not send availability messages until deployment is
> done
> >
> > Isn't this what mod_cluster does on a per-deployment basis anyway? The
> > basic idea of mod_cluster is the LB isn't notified the context is
> > available on a backend server until it's....available.
>
> True, but not everyone is using mod_cluster.
>
> >
> >> - JMS will delay message delivery until deployment is done
> >> - EJB persistent timers will not fire until deployment is done
> >> - Possibly some other cases I can't think of right now
> >>
> >> One thing I am not really sure about is if we need a configuration
> >> switch for hold/reject behavior. e.g. for Undertow the request holding
> >> behavior is very developer friendly, as it means they can just hit
> >> refresh in their browser and as soon as the redeployment is done the
> >> page will display, however I am worried that it might not be ideal for
> >> load balancers that may prefer a quick error response that could then be
> >> attempted on another node (although if mod_cluster is not sending out
> >> availability till the deployment is 100% complete this may not be a big
> >> deal).
> >>
> >> If you want to see this in action I have a very simple PR at [3] that
> >> enables this for Undertow at server boot.
> >>
> >> Thoughts?
> >>
> >> Stuart
> >>
> >> [1] https://issues.jboss.org/browse/WFLY-6402
> >> [2] https://issues.jboss.org/browse/JBEAP-867
> >> [3] https://github.com/wildfly/wildfly/pull/8858
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >
> >
> > --
> > Brian Stansberry
> > Senior Principal Software Engineer
> > JBoss by Red Hat
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 21 Apr 2016 15:39:56 -0500
> From: Brian Stansberry <brian.stansberry at redhat.com>
> Subject: Re: [wildfly-dev] Graceful startup
> To: John Doyle <jdoyle at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Message-ID: <57193A9C.1040103 at redhat.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 4/21/16 2:07 PM, John Doyle wrote:
> > On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
> > <brian.stansberry at redhat.com> wrote:
> >> On 4/20/16 9:05 PM, Stuart Douglas wrote:
> >>> Hi,
> >>>
> >>> I have come across a few bug reports [1][2] (and a feature request from
> >>> the Swarm team) recently that are essentially caused by an application
> >>> being accessed before it is fully deployed. Basically even though we
> >>> have service dependencies that make sure individual components
> >>> dependencies are up, once a request has been accepted it can
> potentially
> >>> programmatically access other parts of the deployment that are not up
> >>> yet (basically the same problem we have with graceful shutdown, but in
> >>> reverse).
> >>>
> >>> I propose we solve this using a 'graceful startup' mechanism, that
> holds
> >>> or rejects new requests until a server or deployment is fully started.
> >>> The specifics of how this would work are:
> >>>
> >>> - If the server is booting all external requests will be held or
> >>> rejected until the the boot process is complete
> >>> - When deploying a new deployment all requests for that deployment will
> >>> be held or rejected until MSC has attained stability
> >>>
> >>> This would be implemented for the following endpoints/subsystems:
> >>>
> >>> - Undertow will hold requests until the deployment is done (so if you
> >>> try and load a page while deployment is happening it could be a bit of
> a
> >>> wait)
> >>> - Remote EJB will hold requests until deployment is done
> >>> - mod_cluster will not send availability messages until deployment is
> done
> >>
> >> Isn't this what mod_cluster does on a per-deployment basis anyway? The
> >> basic idea of mod_cluster is the LB isn't notified the context is
> >> available on a backend server until it's....available.
> >
> > True, but not everyone is using mod_cluster.
> >
>
> Sure, but the statement I was commenting on was about proposed new
> behavior of our mod_cluster subsystem. But the proposed new behavior
> sounds like what the existing behavior should already be. So I wonder if
> I'm missing something.
>
> >>
> >>> - JMS will delay message delivery until deployment is done
> >>> - EJB persistent timers will not fire until deployment is done
> >>> - Possibly some other cases I can't think of right now
> >>>
> >>> One thing I am not really sure about is if we need a configuration
> >>> switch for hold/reject behavior. e.g. for Undertow the request holding
> >>> behavior is very developer friendly, as it means they can just hit
> >>> refresh in their browser and as soon as the redeployment is done the
> >>> page will display, however I am worried that it might not be ideal for
> >>> load balancers that may prefer a quick error response that could then
> be
> >>> attempted on another node (although if mod_cluster is not sending out
> >>> availability till the deployment is 100% complete this may not be a big
> >>> deal).
> >>>
> >>> If you want to see this in action I have a very simple PR at [3] that
> >>> enables this for Undertow at server boot.
> >>>
> >>> Thoughts?
> >>>
> >>> Stuart
> >>>
> >>> [1] https://issues.jboss.org/browse/WFLY-6402
> >>> [2] https://issues.jboss.org/browse/JBEAP-867
> >>> [3] https://github.com/wildfly/wildfly/pull/8858
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>
> >>
> >> --
> >> Brian Stansberry
> >> Senior Principal Software Engineer
> >> JBoss by Red Hat
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 21 Apr 2016 22:59:54 +0000
> From: Stuart Douglas <stuart.w.douglas at gmail.com>
> Subject: Re: [wildfly-dev] Graceful startup
> To: Brian Stansberry <brian.stansberry at redhat.com>,
> wildfly-dev at lists.jboss.org
> Message-ID:
> <CAAoo=c5DAg+yCzMxpzK4BDxfViQDTJnb_vMZz22k4_WwZrHikg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> > > - Undertow will hold requests until the deployment is done (so if you
> > > try and load a page while deployment is happening it could be a bit of
> a
> > > wait)
> > > - Remote EJB will hold requests until deployment is done
> > > - mod_cluster will not send availability messages until deployment is
> > done
> >
> > Isn't this what mod_cluster does on a per-deployment basis anyway? The
> > basic idea of mod_cluster is the LB isn't notified the context is
> > available on a backend server until it's....available.
> >
> >
> At the moment it is sent when the Undertow service comes up. It is still
> possible that there could be other services (especially in a multi module
> EAR deployment) that have not come up yet.
>
> In practice for a lot of deployments this window will be very small or even
> non existent, and the behavior will be basically indistinguishable.
>
> Stuart
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/52d3edbd/attachment.html
>
> ------------------------------
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> End of wildfly-dev Digest, Vol 37, Issue 9
> ******************************************
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160422/caaeb936/attachment-0001.html