<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> &lt;<a href="mailto:gaoyonglu@126.com">gaoyonglu@126.com</a>&gt; 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>&gt; 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 &#39;help&#39; 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 &quot;Re: Contents of wildfly-dev digest...&quot;</div>
<div> </div>
<div> </div>
<div>Today&#39;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: &quot;David M. Lloyd&quot; &lt;<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>&gt;</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: &lt;<a href="mailto:5718BE97.9010405@redhat.com" target="_blank">5718BE97.9010405@redhat.com</a>&gt;</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>&gt; Hi,</div>
<div>&gt;</div>
<div>&gt; I have come across a few bug reports [1][2] (and a feature request 
from</div>
<div>&gt; the Swarm team) recently that are essentially caused by an 
application</div>
<div>&gt; being accessed before it is fully deployed. Basically even though 
we</div>
<div>&gt; have service dependencies that make sure individual components</div>
<div>&gt; dependencies are up, once a request has been accepted it can 
potentially</div>
<div>&gt; programmatically access other parts of the deployment that are not 
up</div>
<div>&gt; yet (basically the same problem we have with graceful shutdown, but 
in</div>
<div>&gt; reverse).</div>
<div>&gt;</div>
<div>&gt; I propose we solve this using a &#39;graceful startup&#39; mechanism, that 
holds</div>
<div>&gt; or rejects new requests until a server or deployment is fully 
started.</div>
<div>&gt; The specifics of how this would work are:</div>
<div>&gt;</div>
<div>&gt; - If the server is booting all external requests will be held or</div>
<div>&gt; rejected until the the boot process is complete</div>
<div>&gt; - When deploying a new deployment all requests for that deployment 
will</div>
<div>&gt; be held or rejected until MSC has attained stability</div>
<div>&gt;</div>
<div>&gt; This would be implemented for the following 
endpoints/subsystems:</div>
<div>&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt; - Undertow will hold requests until the deployment is done (so if 
you</div>
<div>&gt; try and load a page while deployment is happening it could be a bit of 
a</div>
<div>&gt; wait)</div>
<div>&gt; - Remote EJB will hold requests until deployment is done</div>
<div>&gt; - mod_cluster will not send availability messages until deployment is 
done</div>
</div></div><div style="MARGIN:10px"><div><div>&gt; - JMS will delay message delivery until deployment is done</div>
<div>&gt; - EJB persistent timers will not fire until deployment is done</div>
<div>&gt; - Possibly some other cases I can&#39;t think of right now</div>
<div>&gt;</div>
<div>&gt; One thing I am not really sure about is if we need a 
configuration</div>
<div>&gt; switch for hold/reject behavior. e.g. for Undertow the request 
holding</div>
<div>&gt; behavior is very developer friendly, as it means they can just 
hit</div>
<div>&gt; refresh in their browser and as soon as the redeployment is done 
the</div>
<div>&gt; page will display, however I am worried that it might not be ideal 
for</div>
<div>&gt; load balancers that may prefer a quick error response that could then 
be</div>
<div>&gt; attempted on another node (although if mod_cluster is not sending 
out</div>
<div>&gt; availability till the deployment is 100% complete this may not be a 
big</div>
<div>&gt; 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&#39;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 &lt;<a href="mailto:rstryker@redhat.com" target="_blank">rstryker@redhat.com</a>&gt;</div>
<div>Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling 
jee</div>
<div>versions</div>
<div>To: &quot;<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>&quot; &lt;<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a>&gt;</div>
<div>Message-ID: &lt;<a href="mailto:5718FAE5.2020307@redhat.com" target="_blank">5718FAE5.2020307@redhat.com</a>&gt;</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&#39;s causing problems for our eclipse validators.</div>
<div> </div>
<div>Who&#39;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 &lt;<a href="mailto:rstryker@redhat.com" target="_blank">rstryker@redhat.com</a>&gt;</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: &lt;<a href="mailto:5718FC3F.4020300@redhat.com" target="_blank">5718FC3F.4020300@redhat.com</a>&gt;</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>&gt; 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&#39;s </div>
<div>jboss-application.xml.</div>
<div> </div>
<div>&gt; Marek wrote:  I guess you mixed Java EE 6 with JBoss AS 7 
versions here.</div>
<div> </div>
<div>I&#39;ll try to find out where the example is coming from. If it&#39;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&#39;ll dig deeper. Thanks.</div>
<div> </div>
<div>On 04/21/2016 12:08 PM, Rob Stryker wrote:</div>
<div>&gt; Hi guys:</div>
<div>&gt;</div>
<div>&gt; 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>&gt; seems our application schema are intermingling jee versions between 
ee6</div>
<div>&gt; and ee7,  and it&#39;s causing problems for our eclipse 
validators.</div>
<div>&gt;</div>
<div>&gt; Who&#39;s in charge of these schema, specifically? Who would be the 
right</div>
<div>&gt; person to ping to get it fixed?</div>
<div>&gt;</div>
<div>&gt; - Rob Stryker</div></div></div><div style="MARGIN:10px"><div>
<div>&gt; _______________________________________________</div>
<div>&gt; wildfly-dev mailing list</div>
<div>&gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>&gt; <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 &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt;</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: &lt;<a href="mailto:57191FA0.9070800@redhat.com" target="_blank">57191FA0.9070800@redhat.com</a>&gt;</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>&gt; Hi,</div>
<div>&gt;</div>
<div>&gt; I have come across a few bug reports [1][2] (and a feature request 
from</div>
<div>&gt; the Swarm team) recently that are essentially caused by an 
application</div>
<div>&gt; being accessed before it is fully deployed. Basically even though 
we</div>
<div>&gt; have service dependencies that make sure individual components</div>
<div>&gt; dependencies are up, once a request has been accepted it can 
potentially</div>
<div>&gt; programmatically access other parts of the deployment that are not 
up</div>
<div>&gt; yet (basically the same problem we have with graceful shutdown, but 
in</div>
<div>&gt; reverse).</div>
<div>&gt;</div>
<div>&gt; I propose we solve this using a &#39;graceful startup&#39; mechanism, that 
holds</div>
<div>&gt; or rejects new requests until a server or deployment is fully 
started.</div>
<div>&gt; The specifics of how this would work are:</div>
<div>&gt;</div>
<div>&gt; - If the server is booting all external requests will be held or</div>
<div>&gt; rejected until the the boot process is complete</div>
<div>&gt; - When deploying a new deployment all requests for that deployment 
will</div>
<div>&gt; be held or rejected until MSC has attained stability</div>
<div>&gt;</div>
<div>&gt; This would be implemented for the following 
endpoints/subsystems:</div>
<div>&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt; - Undertow will hold requests until the deployment is done (so if 
you</div>
<div>&gt; try and load a page while deployment is happening it could be a bit of 
a</div>
<div>&gt; wait)</div>
<div>&gt; - Remote EJB will hold requests until deployment is done</div>
<div>&gt; - mod_cluster will not send availability messages until deployment is 
done</div>
<div> </div>
<div>Isn&#39;t this what mod_cluster does on a per-deployment basis anyway? The 
</div>
<div>basic idea of mod_cluster is the LB isn&#39;t notified the context is </div>
<div>available on a backend server until it&#39;s....available.</div>
<div> </div>
</div></div><div style="MARGIN:10px"><div><div>&gt; - JMS will delay message delivery until deployment is done</div>
<div>&gt; - EJB persistent timers will not fire until deployment is done</div>
<div>&gt; - Possibly some other cases I can&#39;t think of right now</div>
<div>&gt;</div>
<div>&gt; One thing I am not really sure about is if we need a 
configuration</div>
<div>&gt; switch for hold/reject behavior. e.g. for Undertow the request 
holding</div>
<div>&gt; behavior is very developer friendly, as it means they can just 
hit</div>
<div>&gt; refresh in their browser and as soon as the redeployment is done 
the</div>
<div>&gt; page will display, however I am worried that it might not be ideal 
for</div>
<div>&gt; load balancers that may prefer a quick error response that could then 
be</div>
<div>&gt; attempted on another node (although if mod_cluster is not sending 
out</div>
<div>&gt; availability till the deployment is 100% complete this may not be a 
big</div>
<div>&gt; deal).</div>
<div>&gt;</div>
<div>&gt; If you want to see this in action I have a very simple PR at [3] 
that</div>
<div>&gt; enables this for Undertow at server boot.</div>
<div>&gt;</div>
<div>&gt; Thoughts?</div>
<div>&gt;</div>
<div>&gt; Stuart</div>
<div>&gt;</div>
<div>&gt; [1] <a href="https://issues.jboss.org/browse/WFLY-6402" target="_blank">https://issues.jboss.org/browse/WFLY-6402</a></div>
<div>&gt; [2] <a href="https://issues.jboss.org/browse/JBEAP-867" target="_blank">https://issues.jboss.org/browse/JBEAP-867</a></div>
<div>&gt; [3] <a href="https://github.com/wildfly/wildfly/pull/8858" target="_blank">https://github.com/wildfly/wildfly/pull/8858</a></div>
<div>&gt;</div>
<div>&gt;</div>
<div>&gt;</div>
<div>&gt;</div>
<div>&gt; _______________________________________________</div>
<div>&gt; wildfly-dev mailing list</div>
<div>&gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>&gt; <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></div>
<div>&gt;</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 &lt;<a href="mailto:jdoyle@redhat.com" target="_blank">jdoyle@redhat.com</a>&gt;</div>
<div>Subject: Re: [wildfly-dev] Graceful startup</div>
<div>To: Brian Stansberry &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt;</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>&lt;CAKSM3ocU+B0gXue4fu6JUZ=<a href="mailto:wA_Ov9F3kPRhEeAFU-OAO5GgNNQ@mail.gmail.com" target="_blank">wA_Ov9F3kPRhEeAFU-OAO5GgNNQ@mail.gmail.com</a>&gt;</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>&lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt; wrote:</div>
<div>&gt; On 4/20/16 9:05 PM, Stuart Douglas wrote:</div>
<div>&gt;&gt; Hi,</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; I have come across a few bug reports [1][2] (and a feature request 
from</div>
<div>&gt;&gt; the Swarm team) recently that are essentially caused by an 
application</div>
<div>&gt;&gt; being accessed before it is fully deployed. Basically even though 
we</div>
<div>&gt;&gt; have service dependencies that make sure individual 
components</div>
<div>&gt;&gt; dependencies are up, once a request has been accepted it can 
potentially</div>
<div>&gt;&gt; programmatically access other parts of the deployment that are not 
up</div>
<div>&gt;&gt; yet (basically the same problem we have with graceful shutdown, 
but in</div>
<div>&gt;&gt; reverse).</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; I propose we solve this using a &#39;graceful startup&#39; mechanism, that 
holds</div>
<div>&gt;&gt; or rejects new requests until a server or deployment is fully 
started.</div>
<div>&gt;&gt; The specifics of how this would work are:</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; - If the server is booting all external requests will be held 
or</div>
<div>&gt;&gt; rejected until the the boot process is complete</div>
<div>&gt;&gt; - When deploying a new deployment all requests for that deployment 
will</div>
<div>&gt;&gt; be held or rejected until MSC has attained stability</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; This would be implemented for the following 
endpoints/subsystems:</div>
<div>&gt;&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt;&gt; - Undertow will hold requests until the deployment is done (so if 
you</div>
<div>&gt;&gt; try and load a page while deployment is happening it could be a 
bit of a</div>
<div>&gt;&gt; wait)</div>
<div>&gt;&gt; - Remote EJB will hold requests until deployment is done</div>
<div>&gt;&gt; - mod_cluster will not send availability messages until deployment 
is done</div>
<div>&gt;</div>
<div>&gt; Isn&#39;t this what mod_cluster does on a per-deployment basis anyway? 
The</div>
<div>&gt; basic idea of mod_cluster is the LB isn&#39;t notified the context 
is</div>
<div>&gt; available on a backend server until it&#39;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>&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt;&gt; - JMS will delay message delivery until deployment is done</div>
<div>&gt;&gt; - EJB persistent timers will not fire until deployment is 
done</div>
<div>&gt;&gt; - Possibly some other cases I can&#39;t think of right now</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; One thing I am not really sure about is if we need a 
configuration</div>
<div>&gt;&gt; switch for hold/reject behavior. e.g. for Undertow the request 
holding</div>
<div>&gt;&gt; behavior is very developer friendly, as it means they can just 
hit</div>
<div>&gt;&gt; refresh in their browser and as soon as the redeployment is done 
the</div>
<div>&gt;&gt; page will display, however I am worried that it might not be ideal 
for</div>
<div>&gt;&gt; load balancers that may prefer a quick error response that could 
then be</div>
<div>&gt;&gt; attempted on another node (although if mod_cluster is not sending 
out</div>
<div>&gt;&gt; availability till the deployment is 100% complete this may not be 
a big</div>
<div>&gt;&gt; deal).</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; If you want to see this in action I have a very simple PR at [3] 
that</div>
<div>&gt;&gt; enables this for Undertow at server boot.</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; Thoughts?</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; Stuart</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; [1] <a href="https://issues.jboss.org/browse/WFLY-6402" target="_blank">https://issues.jboss.org/browse/WFLY-6402</a></div>
<div>&gt;&gt; [2] <a href="https://issues.jboss.org/browse/JBEAP-867" target="_blank">https://issues.jboss.org/browse/JBEAP-867</a></div>
<div>&gt;&gt; [3] <a href="https://github.com/wildfly/wildfly/pull/8858" target="_blank">https://github.com/wildfly/wildfly/pull/8858</a></div>
<div>&gt;&gt;</div>
<div>&gt;&gt;</div>
<div>&gt;&gt;</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; _______________________________________________</div>
<div>&gt;&gt; wildfly-dev mailing list</div>
<div>&gt;&gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></div>
<div>&gt;&gt;</div>
<div>&gt;</div>
<div>&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt; --</div>
<div>&gt; Brian Stansberry</div>
<div>&gt; Senior Principal Software Engineer</div>
<div>&gt; JBoss by Red Hat</div>
</div></div><div style="MARGIN:10px"><div><div>&gt; _______________________________________________</div>
<div>&gt; wildfly-dev mailing list</div>
<div>&gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>&gt; <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 &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt;</div>
<div>Subject: Re: [wildfly-dev] Graceful startup</div>
<div>To: John Doyle &lt;<a href="mailto:jdoyle@redhat.com" target="_blank">jdoyle@redhat.com</a>&gt;</div>
<div>Cc: <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>Message-ID: &lt;<a href="mailto:57193A9C.1040103@redhat.com" target="_blank">57193A9C.1040103@redhat.com</a>&gt;</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>&gt; On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry</div>
<div>&gt; &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt; wrote:</div>
<div>&gt;&gt; On 4/20/16 9:05 PM, Stuart Douglas wrote:</div>
<div>&gt;&gt;&gt; Hi,</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; I have come across a few bug reports [1][2] (and a feature 
request from</div>
<div>&gt;&gt;&gt; the Swarm team) recently that are essentially caused by an 
application</div>
<div>&gt;&gt;&gt; being accessed before it is fully deployed. Basically even 
though we</div>
<div>&gt;&gt;&gt; have service dependencies that make sure individual 
components</div>
<div>&gt;&gt;&gt; dependencies are up, once a request has been accepted it can 
potentially</div>
<div>&gt;&gt;&gt; programmatically access other parts of the deployment that are 
not up</div>
<div>&gt;&gt;&gt; yet (basically the same problem we have with graceful 
shutdown, but in</div>
<div>&gt;&gt;&gt; reverse).</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; I propose we solve this using a &#39;graceful startup&#39; mechanism, 
that holds</div>
<div>&gt;&gt;&gt; or rejects new requests until a server or deployment is fully 
started.</div>
<div>&gt;&gt;&gt; The specifics of how this would work are:</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; - If the server is booting all external requests will be held 
or</div>
<div>&gt;&gt;&gt; rejected until the the boot process is complete</div>
<div>&gt;&gt;&gt; - When deploying a new deployment all requests for that 
deployment will</div>
<div>&gt;&gt;&gt; be held or rejected until MSC has attained stability</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; This would be implemented for the following 
endpoints/subsystems:</div>
<div>&gt;&gt;&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt;&gt;&gt; - Undertow will hold requests until the deployment is done (so 
if you</div>
<div>&gt;&gt;&gt; try and load a page while deployment is happening it could be 
a bit of a</div>
<div>&gt;&gt;&gt; wait)</div>
<div>&gt;&gt;&gt; - Remote EJB will hold requests until deployment is done</div>
<div>&gt;&gt;&gt; - mod_cluster will not send availability messages until 
deployment is done</div>
<div>&gt;&gt;</div>
<div>&gt;&gt; Isn&#39;t this what mod_cluster does on a per-deployment basis anyway? 
The</div>
<div>&gt;&gt; basic idea of mod_cluster is the LB isn&#39;t notified the context 
is</div>
<div>&gt;&gt; available on a backend server until it&#39;s....available.</div>
<div>&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt; True, but not everyone is using mod_cluster.</div>
<div>&gt;</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&#39;m missing something.</div>
<div> </div>
<div>&gt;&gt;</div>
<div>&gt;&gt;&gt; - JMS will delay message delivery until deployment is 
done</div>
<div>&gt;&gt;&gt; - EJB persistent timers will not fire until deployment is 
done</div>
<div>&gt;&gt;&gt; - Possibly some other cases I can&#39;t think of right now</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; One thing I am not really sure about is if we need a 
configuration</div>
<div>&gt;&gt;&gt; switch for hold/reject behavior. e.g. for Undertow the request 
holding</div>
<div>&gt;&gt;&gt; behavior is very developer friendly, as it means they can just 
hit</div>
<div>&gt;&gt;&gt; refresh in their browser and as soon as the redeployment is 
done the</div>
<div>&gt;&gt;&gt; page will display, however I am worried that it might not be 
ideal for</div>
<div>&gt;&gt;&gt; load balancers that may prefer a quick error response that 
could then be</div>
<div>&gt;&gt;&gt; attempted on another node (although if mod_cluster is not 
sending out</div>
<div>&gt;&gt;&gt; availability till the deployment is 100% complete this may not 
be a big</div>
<div>&gt;&gt;&gt; deal).</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; If you want to see this in action I have a very simple PR at 
[3] that</div>
<div>&gt;&gt;&gt; enables this for Undertow at server boot.</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; Thoughts?</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; Stuart</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; [1] <a href="https://issues.jboss.org/browse/WFLY-6402" target="_blank">https://issues.jboss.org/browse/WFLY-6402</a></div>
<div>&gt;&gt;&gt; [2] <a href="https://issues.jboss.org/browse/JBEAP-867" target="_blank">https://issues.jboss.org/browse/JBEAP-867</a></div>
<div>&gt;&gt;&gt; [3] <a href="https://github.com/wildfly/wildfly/pull/8858" target="_blank">https://github.com/wildfly/wildfly/pull/8858</a></div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;&gt; _______________________________________________</div>
<div>&gt;&gt;&gt; wildfly-dev mailing list</div>
<div>&gt;&gt;&gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a></div>
<div>&gt;&gt;&gt;</div>
<div>&gt;&gt;</div>
<div>&gt;&gt;</div>
</div></div><div style="MARGIN:10px"><div><div>&gt;&gt; --</div>
<div>&gt;&gt; Brian Stansberry</div>
<div>&gt;&gt; Senior Principal Software Engineer</div>
<div>&gt;&gt; JBoss by Red Hat</div>
</div></div><div style="MARGIN:10px"><div><div>&gt;&gt; _______________________________________________</div>
<div>&gt;&gt; wildfly-dev mailing list</div>
<div>&gt;&gt; <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>&gt;&gt; <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 &lt;<a href="mailto:stuart.w.douglas@gmail.com" target="_blank">stuart.w.douglas@gmail.com</a>&gt;</div>
<div>Subject: Re: [wildfly-dev] Graceful startup</div>
<div>To: Brian Stansberry &lt;<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>&gt;,</div>
<div><a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a></div>
<div>Message-ID:</div>
<div>&lt;CAAoo=<a href="mailto:c5DAg%2ByCzMxpzK4BDxfViQDTJnb_vMZz22k4_WwZrHikg@mail.gmail.com" target="_blank">c5DAg+yCzMxpzK4BDxfViQDTJnb_vMZz22k4_WwZrHikg@mail.gmail.com</a>&gt;</div>
<div>Content-Type: text/plain; charset=&quot;utf-8&quot;</div></div></div><div style="MARGIN:10px"><div>
<div> </div>
<div>&gt; &gt; - Undertow will hold requests until the deployment is done (so if 
you</div>
<div>&gt; &gt; try and load a page while deployment is happening it could be a 
bit of a</div>
<div>&gt; &gt; wait)</div>
<div>&gt; &gt; - Remote EJB will hold requests until deployment is done</div>
<div>&gt; &gt; - mod_cluster will not send availability messages until 
deployment is</div>
<div>&gt; done</div>
<div>&gt;</div>
<div>&gt; Isn&#39;t this what mod_cluster does on a per-deployment basis anyway? 
The</div>
<div>&gt; basic idea of mod_cluster is the LB isn&#39;t notified the context 
is</div>
<div>&gt; available on a backend server until it&#39;s....available.</div>
<div>&gt;</div>
<div>&gt;</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>