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