<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=utf-8" http-equiv=Content-Type>
<STYLE>
BLOCKQUOTE {
MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em; MARGIN-TOP: 0px
}
OL {
MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
UL {
MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
P {
MARGIN-BOTTOM: 0px; MARGIN-TOP: 0px
}
BODY {
FONT-SIZE: 10.5pt; FONT-FAMILY: 微软雅黑; COLOR: #000000; LINE-HEIGHT: 1.5
}
</STYLE>
<META name=GENERATOR content="MSHTML 11.00.9600.18283"></HEAD>
<BODY style="MARGIN: 10px">
<DIV> </DIV>
<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>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="HEIGHT: 1px; WIDTH: 210px" align=left color=#b5c4df SIZE=1>
<DIV><SPAN>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: verdana; MARGIN: 10px">
<DIV>gaoyonglu@126.com</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">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">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>wildfly-dev@lists.jboss.org</DIV>
<DIV> </DIV>
<DIV>To subscribe or unsubscribe via the World Wide Web, visit</DIV>
<DIV>https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV>or, via email, send a message with subject or body 'help' to</DIV>
<DIV>wildfly-dev-request@lists.jboss.org</DIV>
<DIV> </DIV>
<DIV>You can reach the person managing the list at</DIV>
<DIV>wildfly-dev-owner@lists.jboss.org</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" <david.lloyd@redhat.com></DIV>
<DIV>Subject: Re: [wildfly-dev] Graceful startup</DIV>
<DIV>To: wildfly-dev@lists.jboss.org</DIV>
<DIV>Message-ID: <5718BE97.9010405@redhat.com></DIV>
<DIV>Content-Type: text/plain; charset=utf-8; format=flowed</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>> - 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>> - 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>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> </DIV>
<DIV>Message: 2</DIV>
<DIV>Date: Thu, 21 Apr 2016 12:08:05 -0400</DIV>
<DIV>From: Rob Stryker <rstryker@redhat.com></DIV>
<DIV>Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling
jee</DIV>
<DIV>versions</DIV>
<DIV>To: "wildfly-dev@lists.jboss.org" <wildfly-dev@lists.jboss.org></DIV>
<DIV>Message-ID: <5718FAE5.2020307@redhat.com></DIV>
<DIV>Content-Type: text/plain; charset=utf-8; format=flowed</DIV>
<DIV> </DIV>
<DIV>Hi guys:</DIV>
<DIV> </DIV>
<DIV>I recently opened https://issues.jboss.org/browse/JBMETA-394 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 <rstryker@redhat.com></DIV>
<DIV>Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd
intermingling</DIV>
<DIV>jee versions</DIV>
<DIV>To: wildfly-dev@lists.jboss.org</DIV>
<DIV>Message-ID: <5718FC3F.4020300@redhat.com></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 https://issues.jboss.org/browse/JBMETA-394 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 https://issues.jboss.org/browse/JBMETA-394 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>> wildfly-dev mailing list</DIV>
<DIV>> wildfly-dev@lists.jboss.org</DIV>
<DIV>> https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>------------------------------</DIV>
<DIV> </DIV>
<DIV>Message: 4</DIV>
<DIV>Date: Thu, 21 Apr 2016 13:44:48 -0500</DIV>
<DIV>From: Brian Stansberry <brian.stansberry@redhat.com></DIV>
<DIV>Subject: Re: [wildfly-dev] Graceful startup</DIV>
<DIV>To: wildfly-dev@lists.jboss.org</DIV>
<DIV>Message-ID: <57191FA0.9070800@redhat.com></DIV>
<DIV>Content-Type: text/plain; charset=windows-1252; format=flowed</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>> - 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>> - 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] https://issues.jboss.org/browse/WFLY-6402</DIV>
<DIV>> [2] https://issues.jboss.org/browse/JBEAP-867</DIV>
<DIV>> [3] https://github.com/wildfly/wildfly/pull/8858</DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>> _______________________________________________</DIV>
<DIV>> wildfly-dev mailing list</DIV>
<DIV>> wildfly-dev@lists.jboss.org</DIV>
<DIV>> https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV>></DIV>
<DIV> </DIV>
<DIV> </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> </DIV>
<DIV>Message: 5</DIV>
<DIV>Date: Thu, 21 Apr 2016 15:07:18 -0400</DIV>
<DIV>From: John Doyle <jdoyle@redhat.com></DIV>
<DIV>Subject: Re: [wildfly-dev] Graceful startup</DIV>
<DIV>To: Brian Stansberry <brian.stansberry@redhat.com></DIV>
<DIV>Cc: wildfly-dev@lists.jboss.org</DIV>
<DIV>Message-ID:</DIV>
<DIV><CAKSM3ocU+B0gXue4fu6JUZ=wA_Ov9F3kPRhEeAFU-OAO5GgNNQ@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset=UTF-8</DIV>
<DIV> </DIV>
<DIV>On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry</DIV>
<DIV><brian.stansberry@redhat.com> 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>>> - 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>True, but not everyone is using mod_cluster.</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] https://issues.jboss.org/browse/WFLY-6402</DIV>
<DIV>>> [2] https://issues.jboss.org/browse/JBEAP-867</DIV>
<DIV>>> [3] https://github.com/wildfly/wildfly/pull/8858</DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>> _______________________________________________</DIV>
<DIV>>> wildfly-dev mailing list</DIV>
<DIV>>> wildfly-dev@lists.jboss.org</DIV>
<DIV>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV>>></DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>> --</DIV>
<DIV>> Brian Stansberry</DIV>
<DIV>> Senior Principal Software Engineer</DIV>
<DIV>> JBoss by Red Hat</DIV>
<DIV>> _______________________________________________</DIV>
<DIV>> wildfly-dev mailing list</DIV>
<DIV>> wildfly-dev@lists.jboss.org</DIV>
<DIV>> https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>------------------------------</DIV>
<DIV> </DIV>
<DIV>Message: 6</DIV>
<DIV>Date: Thu, 21 Apr 2016 15:39:56 -0500</DIV>
<DIV>From: Brian Stansberry <brian.stansberry@redhat.com></DIV>
<DIV>Subject: Re: [wildfly-dev] Graceful startup</DIV>
<DIV>To: John Doyle <jdoyle@redhat.com></DIV>
<DIV>Cc: wildfly-dev@lists.jboss.org</DIV>
<DIV>Message-ID: <57193A9C.1040103@redhat.com></DIV>
<DIV>Content-Type: text/plain; charset=utf-8; format=flowed</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>> <brian.stansberry@redhat.com> 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>>>> - 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>> 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] https://issues.jboss.org/browse/WFLY-6402</DIV>
<DIV>>>> [2] https://issues.jboss.org/browse/JBEAP-867</DIV>
<DIV>>>> [3] https://github.com/wildfly/wildfly/pull/8858</DIV>
<DIV>>>></DIV>
<DIV>>>></DIV>
<DIV>>>></DIV>
<DIV>>>></DIV>
<DIV>>>> _______________________________________________</DIV>
<DIV>>>> wildfly-dev mailing list</DIV>
<DIV>>>> wildfly-dev@lists.jboss.org</DIV>
<DIV>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV>>>></DIV>
<DIV>>></DIV>
<DIV>>></DIV>
<DIV>>> --</DIV>
<DIV>>> Brian Stansberry</DIV>
<DIV>>> Senior Principal Software Engineer</DIV>
<DIV>>> JBoss by Red Hat</DIV>
<DIV>>> _______________________________________________</DIV>
<DIV>>> wildfly-dev mailing list</DIV>
<DIV>>> wildfly-dev@lists.jboss.org</DIV>
<DIV>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV> </DIV>
<DIV> </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> </DIV>
<DIV>Message: 7</DIV>
<DIV>Date: Thu, 21 Apr 2016 22:59:54 +0000</DIV>
<DIV>From: Stuart Douglas <stuart.w.douglas@gmail.com></DIV>
<DIV>Subject: Re: [wildfly-dev] Graceful startup</DIV>
<DIV>To: Brian Stansberry <brian.stansberry@redhat.com>,</DIV>
<DIV>wildfly-dev@lists.jboss.org</DIV>
<DIV>Message-ID:</DIV>
<DIV><CAAoo=c5DAg+yCzMxpzK4BDxfViQDTJnb_vMZz22k4_WwZrHikg@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset="utf-8"</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>Stuart</DIV>
<DIV>-------------- next part --------------</DIV>
<DIV>An HTML attachment was scrubbed...</DIV>
<DIV>URL:
http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/52d3edbd/attachment.html
</DIV>
<DIV> </DIV>
<DIV>------------------------------</DIV>
<DIV> </DIV>
<DIV>_______________________________________________</DIV>
<DIV>wildfly-dev mailing list</DIV>
<DIV>wildfly-dev@lists.jboss.org</DIV>
<DIV>https://lists.jboss.org/mailman/listinfo/wildfly-dev</DIV>
<DIV> </DIV>
<DIV>End of wildfly-dev Digest, Vol 37, Issue 9</DIV>
<DIV>******************************************</DIV></DIV></BODY></HTML>