One thing I am not really sure about is if we need a configuration> switch for hold/reject behaviorI 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
From: wildfly-dev-requestDate: 2016-04-22 07:00To: wildfly-devSubject: wildfly-dev Digest, Vol 37, Issue 9Send wildfly-dev mailing list submissions toTo subscribe or unsubscribe via the World Wide Web, visitor, via email, send a message with subject or body 'help' toYou can reach the person managing the list atWhen replying, please edit your Subject line so it is more specificthan "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: 1Date: Thu, 21 Apr 2016 06:50:47 -0500From: "David M. Lloyd" <david.lloyd@redhat.com>Subject: Re: [wildfly-dev] Graceful startupMessage-ID: <5718BE97.9010405@redhat.com>Content-Type: text/plain; charset=utf-8; format=flowedOn 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 upin the rotation anyway; this already probably doesn't work great today.I like the idea overall.--- DML------------------------------Message: 2Date: Thu, 21 Apr 2016 12:08:05 -0400From: Rob Stryker <rstryker@redhat.com>Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jeeversionsMessage-ID: <5718FAE5.2020307@redhat.com>Content-Type: text/plain; charset=utf-8; format=flowedHi guys:I recently opened https://issues.jboss.org/browse/JBMETA-394 because itseems our application schema are intermingling jee versions between ee6and ee7, and it's causing problems for our eclipse validators.Who's in charge of these schema, specifically? Who would be the rightperson to ping to get it fixed?- Rob Stryker------------------------------Message: 3Date: Thu, 21 Apr 2016 12:13:51 -0400From: Rob Stryker <rstryker@redhat.com>Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd interminglingjee versionsMessage-ID: <5718FC3F.4020300@redhat.com>Content-Type: text/plain; charset=windows-1252; format=flowedOk, seems I missed some responses before.> Max Anderson wrote: Rob - is the error you see on thejboss-application.xml you wrote or in the included xsd ?I opened https://issues.jboss.org/browse/JBMETA-394 for a more clearexplanation as to the specific error. The error is in a user'sjboss-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 oneof our published examples, then I would guess it needs to be fixedthere. Looking at the released versions of jboss-app_x_y.xsd, it wouldseem Marek is probably right and the versions there match the jboss/wfreleases, 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------------------------------Message: 4Date: Thu, 21 Apr 2016 13:44:48 -0500From: Brian Stansberry <brian.stansberry@redhat.com>Subject: Re: [wildfly-dev] Graceful startupMessage-ID: <57191FA0.9070800@redhat.com>Content-Type: text/plain; charset=windows-1252; format=flowedOn 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 doneIsn't this what mod_cluster does on a per-deployment basis anyway? Thebasic idea of mod_cluster is the LB isn't notified the context isavailable 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>>>>>> _______________________________________________> wildfly-dev mailing list>--Brian StansberrySenior Principal Software EngineerJBoss by Red Hat------------------------------Message: 5Date: Thu, 21 Apr 2016 15:07:18 -0400From: John Doyle <jdoyle@redhat.com>Subject: Re: [wildfly-dev] Graceful startupTo: Brian Stansberry <brian.stansberry@redhat.com>Message-ID:<CAKSM3ocU+B0gXue4fu6JUZ=wA_Ov9F3kPRhEeAFU-OAO5GgNNQ@mail.gmail.com>Content-Type: text/plain; charset=UTF-8On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry<brian.stansberry@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>>>>>>>>>>>> _______________________________________________>> wildfly-dev mailing list>>>>> --> Brian Stansberry> Senior Principal Software Engineer> JBoss by Red Hat> _______________________________________________> wildfly-dev mailing list------------------------------Message: 6Date: Thu, 21 Apr 2016 15:39:56 -0500From: Brian Stansberry <brian.stansberry@redhat.com>Subject: Re: [wildfly-dev] Graceful startupTo: John Doyle <jdoyle@redhat.com>Message-ID: <57193A9C.1040103@redhat.com>Content-Type: text/plain; charset=utf-8; format=flowedOn 4/21/16 2:07 PM, John Doyle wrote:> On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry> <brian.stansberry@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 newbehavior of our mod_cluster subsystem. But the proposed new behaviorsounds like what the existing behavior should already be. So I wonder ifI'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>>>>>>>>>>>>>>>>>> _______________________________________________>>> wildfly-dev mailing list>>>>>>>>> -->> Brian Stansberry>> Senior Principal Software Engineer>> JBoss by Red Hat>> _______________________________________________>> wildfly-dev mailing list--Brian StansberrySenior Principal Software EngineerJBoss by Red Hat------------------------------Message: 7Date: Thu, 21 Apr 2016 22:59:54 +0000From: Stuart Douglas <stuart.w.douglas@gmail.com>Subject: Re: [wildfly-dev] Graceful startupTo: Brian Stansberry <brian.stansberry@redhat.com>,Message-ID: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 stillpossible that there could be other services (especially in a multi moduleEAR deployment) that have not come up yet.In practice for a lot of deployments this window will be very small or evennon existent, and the behavior will be basically indistinguishable.Stuart-------------- next part --------------An HTML attachment was scrubbed...------------------------------_______________________________________________wildfly-dev mailing list_______________________________________________End of wildfly-dev Digest, Vol 37, Issue 9******************************************
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev