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(a)126.com *From:* wildfly-dev-request <wildfly-dev-request(a)lists.jboss.org&gt; *Date:* 2016-04-22 07:00 *To:* wildfly-dev <wildfly-dev(a)lists.jboss.org&gt; *Subject:* wildfly-dev Digest, Vol 37, Issue 9 Send wildfly-dev mailing list submissions to wildfly-dev(a)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(a)lists.jboss.org You can reach the person managing the list at wildfly-dev-owner(a)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(a)redhat.com&gt; Subject: Re: [wildfly-dev] Graceful startup To: wildfly-dev(a)lists.jboss.org Message-ID: <5718BE97.9010405(a)redhat.com&gt; 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(a)redhat.com&gt; Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee versions To: &quot;wildfly-dev(a)lists.jboss.org&quot; <wildfly-dev(a)lists.jboss.org&gt; Message-ID: <5718FAE5.2020307(a)redhat.com&gt; 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(a)redhat.com&gt; Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee versions To: wildfly-dev(a)lists.jboss.org Message-ID: <5718FC3F.4020300(a)redhat.com&gt; 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(a)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(a)redhat.com&gt; Subject: Re: [wildfly-dev] Graceful startup To: wildfly-dev(a)lists.jboss.org Message-ID: <57191FA0.9070800(a)redhat.com&gt; 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(a)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(a)redhat.com&gt; Subject: Re: [wildfly-dev] Graceful startup To: Brian Stansberry <brian.stansberry(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Message-ID: <CAKSM3ocU+B0gXue4fu6JUZ=wA_Ov9F3kPRhEeAFU-OAO5GgNNQ(a)mail.gmail.com&gt; Content-Type: text/plain; charset=UTF-8 On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; 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(a)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(a)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(a)redhat.com&gt; Subject: Re: [wildfly-dev] Graceful startup To: John Doyle <jdoyle(a)redhat.com&gt; Cc: wildfly-dev(a)lists.jboss.org Message-ID: <57193A9C.1040103(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)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(a)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(a)gmail.com&gt; Subject: Re: [wildfly-dev] Graceful startup To: Brian Stansberry <brian.stansberry(a)redhat.com&gt;, wildfly-dev(a)lists.jboss.org Message-ID: <CAAoo=c5DAg+yCzMxpzK4BDxfViQDTJnb_vMZz22k4_WwZrHikg(a)mail.gmail.com&gt; 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/52d3edb... ------------------------------ _______________________________________________ wildfly-dev mailing list wildfly-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

How would suspend/resume be applied in this situation? I think we speak about server startup, right?

On 22 Apr 2016, at 05:00, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; wrote: If the user really wants reject behavior they can uses suspend/resume to achieve this. _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev