[wildfly-dev] Graceful startup

Thu Apr 21 22:00:12 EDT 2016

One thing I am not really sure about is if we need a configuration
> switch for hold/reject behavior

I think use reject is better. The weblogic server start graceful use reject and if use hold option we must set queue to hold request.

I  very much looking forward to this feature 

gaoyonglu at 126.com

From: wildfly-dev-request
Date: 2016-04-22 07:00
To: wildfly-dev
Subject: wildfly-dev Digest, Vol 37, Issue 9
Send wildfly-dev mailing list submissions to
wildfly-dev at lists.jboss.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.jboss.org/mailman/listinfo/wildfly-dev
or, via email, send a message with subject or body 'help' to
wildfly-dev-request at lists.jboss.org

You can reach the person managing the list at
wildfly-dev-owner at lists.jboss.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of wildfly-dev digest..."

Today's Topics:

   1. Re: Graceful startup (David M. Lloyd)
   2. question on jboss-app_7_0.xsd intermingling jee versions
      (Rob Stryker)
   3. Re: question on jboss-app_7_0.xsd intermingling jee versions
      (Rob Stryker)
   4. Re: Graceful startup (Brian Stansberry)
   5. Re: Graceful startup (John Doyle)
   6. Re: Graceful startup (Brian Stansberry)
   7. Re: Graceful startup (Stuart Douglas)

----------------------------------------------------------------------

Message: 1
Date: Thu, 21 Apr 2016 06:50:47 -0500
From: "David M. Lloyd" <david.lloyd at redhat.com>
Subject: Re: [wildfly-dev] Graceful startup
To: wildfly-dev at lists.jboss.org
Message-ID: <5718BE97.9010405 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 04/20/2016 09:05 PM, Stuart Douglas wrote:
> Hi,
>
> I have come across a few bug reports [1][2] (and a feature request from
> the Swarm team) recently that are essentially caused by an application
> being accessed before it is fully deployed. Basically even though we
> have service dependencies that make sure individual components
> dependencies are up, once a request has been accepted it can potentially
> programmatically access other parts of the deployment that are not up
> yet (basically the same problem we have with graceful shutdown, but in
> reverse).
>
> I propose we solve this using a 'graceful startup' mechanism, that holds
> or rejects new requests until a server or deployment is fully started.
> The specifics of how this would work are:
>
> - If the server is booting all external requests will be held or
> rejected until the the boot process is complete
> - When deploying a new deployment all requests for that deployment will
> be held or rejected until MSC has attained stability
>
> This would be implemented for the following endpoints/subsystems:
>
> - Undertow will hold requests until the deployment is done (so if you
> try and load a page while deployment is happening it could be a bit of a
> wait)
> - Remote EJB will hold requests until deployment is done
> - mod_cluster will not send availability messages until deployment is done
> - JMS will delay message delivery until deployment is done
> - EJB persistent timers will not fire until deployment is done
> - Possibly some other cases I can't think of right now
>
> One thing I am not really sure about is if we need a configuration
> switch for hold/reject behavior. e.g. for Undertow the request holding
> behavior is very developer friendly, as it means they can just hit
> refresh in their browser and as soon as the redeployment is done the
> page will display, however I am worried that it might not be ideal for
> load balancers that may prefer a quick error response that could then be
> attempted on another node (although if mod_cluster is not sending out
> availability till the deployment is 100% complete this may not be a big
> deal).

I think load balancers should not have a server that is being started up 
in the rotation anyway; this already probably doesn't work great today.

I like the idea overall.

-- 
- DML

------------------------------

Message: 2
Date: Thu, 21 Apr 2016 12:08:05 -0400
From: Rob Stryker <rstryker at redhat.com>
Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee
versions
To: "wildfly-dev at lists.jboss.org" <wildfly-dev at lists.jboss.org>
Message-ID: <5718FAE5.2020307 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi guys:

I recently opened https://issues.jboss.org/browse/JBMETA-394 because it 
seems our application schema are intermingling jee versions between ee6 
and ee7,  and it's causing problems for our eclipse validators.

Who's in charge of these schema, specifically? Who would be the right 
person to ping to get it fixed?

- Rob Stryker

------------------------------

Message: 3
Date: Thu, 21 Apr 2016 12:13:51 -0400
From: Rob Stryker <rstryker at redhat.com>
Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd intermingling
jee versions
To: wildfly-dev at lists.jboss.org
Message-ID: <5718FC3F.4020300 at redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

Ok, seems I missed some responses before.

> Max Anderson wrote:   Rob - is the error you see on the 
jboss-application.xml you wrote or in  the included xsd ?

I opened https://issues.jboss.org/browse/JBMETA-394  for a more clear 
explanation as to the specific error. The error is in a user's 
jboss-application.xml.

> Marek wrote:  I guess you mixed Java EE 6 with JBoss AS 7 versions here.

I'll try to find out where the example is coming from. If it's from one 
of our published examples, then I would guess it needs to be fixed 
there. Looking at the released versions of jboss-app_x_y.xsd,  it would 
seem Marek is probably right and the versions there match the jboss/wf 
releases, and not the ee version.

I'll dig deeper. Thanks.

On 04/21/2016 12:08 PM, Rob Stryker wrote:
> Hi guys:
>
> I recently opened https://issues.jboss.org/browse/JBMETA-394 because it
> seems our application schema are intermingling jee versions between ee6
> and ee7,  and it's causing problems for our eclipse validators.
>
> Who's in charge of these schema, specifically? Who would be the right
> person to ping to get it fixed?
>
> - Rob Stryker
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

------------------------------

Message: 4
Date: Thu, 21 Apr 2016 13:44:48 -0500
From: Brian Stansberry <brian.stansberry at redhat.com>
Subject: Re: [wildfly-dev] Graceful startup
To: wildfly-dev at lists.jboss.org
Message-ID: <57191FA0.9070800 at redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

On 4/20/16 9:05 PM, Stuart Douglas wrote:
> Hi,
>
> I have come across a few bug reports [1][2] (and a feature request from
> the Swarm team) recently that are essentially caused by an application
> being accessed before it is fully deployed. Basically even though we
> have service dependencies that make sure individual components
> dependencies are up, once a request has been accepted it can potentially
> programmatically access other parts of the deployment that are not up
> yet (basically the same problem we have with graceful shutdown, but in
> reverse).
>
> I propose we solve this using a 'graceful startup' mechanism, that holds
> or rejects new requests until a server or deployment is fully started.
> The specifics of how this would work are:
>
> - If the server is booting all external requests will be held or
> rejected until the the boot process is complete
> - When deploying a new deployment all requests for that deployment will
> be held or rejected until MSC has attained stability
>
> This would be implemented for the following endpoints/subsystems:
>
> - Undertow will hold requests until the deployment is done (so if you
> try and load a page while deployment is happening it could be a bit of a
> wait)
> - Remote EJB will hold requests until deployment is done
> - mod_cluster will not send availability messages until deployment is done

Isn't this what mod_cluster does on a per-deployment basis anyway? The 
basic idea of mod_cluster is the LB isn't notified the context is 
available on a backend server until it's....available.

> - JMS will delay message delivery until deployment is done
> - EJB persistent timers will not fire until deployment is done
> - Possibly some other cases I can't think of right now
>
> One thing I am not really sure about is if we need a configuration
> switch for hold/reject behavior. e.g. for Undertow the request holding
> behavior is very developer friendly, as it means they can just hit
> refresh in their browser and as soon as the redeployment is done the
> page will display, however I am worried that it might not be ideal for
> load balancers that may prefer a quick error response that could then be
> attempted on another node (although if mod_cluster is not sending out
> availability till the deployment is 100% complete this may not be a big
> deal).
>
> If you want to see this in action I have a very simple PR at [3] that
> enables this for Undertow at server boot.
>
> Thoughts?
>
> Stuart
>
> [1] https://issues.jboss.org/browse/WFLY-6402
> [2] https://issues.jboss.org/browse/JBEAP-867
> [3] https://github.com/wildfly/wildfly/pull/8858
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

------------------------------

Message: 5
Date: Thu, 21 Apr 2016 15:07:18 -0400
From: John Doyle <jdoyle at redhat.com>
Subject: Re: [wildfly-dev] Graceful startup
To: Brian Stansberry <brian.stansberry at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Message-ID:
<CAKSM3ocU+B0gXue4fu6JUZ=wA_Ov9F3kPRhEeAFU-OAO5GgNNQ at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
<brian.stansberry at 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
>>
>> [1] https://issues.jboss.org/browse/WFLY-6402
>> [2] https://issues.jboss.org/browse/JBEAP-867
>> [3] https://github.com/wildfly/wildfly/pull/8858
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

------------------------------

Message: 6
Date: Thu, 21 Apr 2016 15:39:56 -0500
From: Brian Stansberry <brian.stansberry at redhat.com>
Subject: Re: [wildfly-dev] Graceful startup
To: John Doyle <jdoyle at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Message-ID: <57193A9C.1040103 at redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 4/21/16 2:07 PM, John Doyle wrote:
> On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
> <brian.stansberry at 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 new 
behavior of our mod_cluster subsystem. But the proposed new behavior 
sounds like what the existing behavior should already be. So I wonder if 
I'm missing something.

>>
>>> - JMS will delay message delivery until deployment is done
>>> - EJB persistent timers will not fire until deployment is done
>>> - Possibly some other cases I can't think of right now
>>>
>>> One thing I am not really sure about is if we need a configuration
>>> switch for hold/reject behavior. e.g. for Undertow the request holding
>>> behavior is very developer friendly, as it means they can just hit
>>> refresh in their browser and as soon as the redeployment is done the
>>> page will display, however I am worried that it might not be ideal for
>>> load balancers that may prefer a quick error response that could then be
>>> attempted on another node (although if mod_cluster is not sending out
>>> availability till the deployment is 100% complete this may not be a big
>>> deal).
>>>
>>> If you want to see this in action I have a very simple PR at [3] that
>>> enables this for Undertow at server boot.
>>>
>>> Thoughts?
>>>
>>> Stuart
>>>
>>> [1] https://issues.jboss.org/browse/WFLY-6402
>>> [2] https://issues.jboss.org/browse/JBEAP-867
>>> [3] https://github.com/wildfly/wildfly/pull/8858
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

------------------------------

Message: 7
Date: Thu, 21 Apr 2016 22:59:54 +0000
From: Stuart Douglas <stuart.w.douglas at gmail.com>
Subject: Re: [wildfly-dev] Graceful startup
To: Brian Stansberry <brian.stansberry at redhat.com>,
wildfly-dev at lists.jboss.org
Message-ID:
<CAAoo=c5DAg+yCzMxpzK4BDxfViQDTJnb_vMZz22k4_WwZrHikg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

> > - Undertow will hold requests until the deployment is done (so if you
> > try and load a page while deployment is happening it could be a bit of a
> > wait)
> > - Remote EJB will hold requests until deployment is done
> > - mod_cluster will not send availability messages until deployment is
> done
>
> Isn't this what mod_cluster does on a per-deployment basis anyway? The
> basic idea of mod_cluster is the LB isn't notified the context is
> available on a backend server until it's....available.
>
>
At the moment it is sent when the Undertow service comes up. It is still
possible that there could be other services (especially in a multi module
EAR deployment) that have not come up yet.

In practice for a lot of deployments this window will be very small or even
non existent, and the behavior will be basically indistinguishable.

Stuart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160421/52d3edbd/attachment.html 

------------------------------

_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

End of wildfly-dev Digest, Vol 37, Issue 9
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160422/a577246c/attachment-0001.html 