Graceful startup

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Graceful startup

Stuart Douglas
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).

If you want to see this in action I have a very simple PR at [3] that enables this for Undertow at server boot.

Thoughts?

Stuart

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Tomaž Cerar-2

On Thu, Apr 21, 2016 at 4:05 AM, Stuart Douglas <[hidden email]> wrote:
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).


Wouldn't for load balancers be better to just return 503 instead? This is similar to what we have with "default-response-code" config for host,
with only difference being that would also make sure other subsystems are up as well.

--
tomaz

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

David Lloyd-2
In reply to this post by Stuart Douglas
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
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Brian Stansberry
In reply to this post by Stuart Douglas
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

John Doyle
On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
<[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Brian Stansberry
On 4/21/16 2:07 PM, John Doyle wrote:

> On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
> <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Stuart Douglas
In reply to this post by Brian Stansberry

> - 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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Brian Stansberry
On 4/21/16 5:59 PM, Stuart Douglas wrote:

>
>      > - 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.
>

Thanks. That's a good hole to close.

> Stuart


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

高永露
In reply to this post by Stuart Douglas

 
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

 
Date: 2016-04-22 07:00
Subject: wildfly-dev Digest, Vol 37, Issue 9
Send wildfly-dev mailing list submissions to
 
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
 
You can reach the person managing the list at
 
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" <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee
versions
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd intermingling
jee versions
Message-ID: <[hidden email]>
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
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
 
 
 
------------------------------
 
Message: 4
Date: Thu, 21 Apr 2016 13:44:48 -0500
From: Brian Stansberry <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
Message-ID: <[hidden email]>
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
> 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 <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
To: Brian Stansberry <[hidden email]>
Message-ID:
<CAKSM3ocU+B0gXue4fu6JUZ=[hidden email]>
Content-Type: text/plain; charset=UTF-8
 
On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
> 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
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
 
 
------------------------------
 
Message: 6
Date: Thu, 21 Apr 2016 15:39:56 -0500
From: Brian Stansberry <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
To: John Doyle <[hidden email]>
Message-ID: <[hidden email]>
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
> <[hidden email]> 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
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> 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 <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
To: Brian Stansberry <[hidden email]>,
Message-ID:
Content-Type: text/plain; charset="utf-8"
 
> > - Undertow will hold requests until the deployment is done (so if you
> > try and load a page while deployment is happening it could be a bit of a
> > wait)
> > - Remote EJB will hold requests until deployment is done
> > - mod_cluster will not send availability messages until deployment is
> done
>
> Isn't this what mod_cluster does on a per-deployment basis anyway? The
> basic idea of mod_cluster is the LB isn't notified the context is
> available on a backend server until it's....available.
>
>
At the moment it is sent when the Undertow service comes up. It is 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
https://lists.jboss.org/mailman/listinfo/wildfly-dev
 
End of wildfly-dev Digest, Vol 37, Issue 9
******************************************

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Stuart Douglas
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.

Stuart

On Fri, 22 Apr 2016 at 12:00 [hidden email] <[hidden email]> wrote:
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

 
Date: 2016-04-22 07:00
Subject: wildfly-dev Digest, Vol 37, Issue 9
Send wildfly-dev mailing list submissions to
 
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
 
You can reach the person managing the list at
 
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" <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: [wildfly-dev] question on jboss-app_7_0.xsd intermingling jee
versions
Message-ID: <[hidden email]>
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 <[hidden email]>
Subject: Re: [wildfly-dev] question on jboss-app_7_0.xsd intermingling
jee versions
Message-ID: <[hidden email]>
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
 
 
 
------------------------------
 
Message: 4
Date: Thu, 21 Apr 2016 13:44:48 -0500
From: Brian Stansberry <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
Message-ID: <[hidden email]>
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
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
>
 
 
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
 
 
------------------------------
 
Message: 5
Date: Thu, 21 Apr 2016 15:07:18 -0400
From: John Doyle <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
To: Brian Stansberry <[hidden email]>
Message-ID:
<CAKSM3ocU+B0gXue4fu6JUZ=[hidden email]>
Content-Type: text/plain; charset=UTF-8
 
On Thu, Apr 21, 2016 at 2:44 PM, Brian Stansberry
> On 4/20/16 9:05 PM, Stuart Douglas wrote:
>> Hi,
>>
>> I have come across a few bug reports [1][2] (and a feature request from
>> the Swarm team) recently that are essentially caused by an application
>> being accessed before it is fully deployed. Basically even though we
>> have service dependencies that make sure individual components
>> dependencies are up, once a request has been accepted it can potentially
>> programmatically access other parts of the deployment that are not up
>> yet (basically the same problem we have with graceful shutdown, but in
>> reverse).
>>
>> I propose we solve this using a 'graceful startup' mechanism, that holds
>> or rejects new requests until a server or deployment is fully started.
>> The specifics of how this would work are:
>>
>> - If the server is booting all external requests will be held or
>> rejected until the the boot process is complete
>> - When deploying a new deployment all requests for that deployment will
>> be held or rejected until MSC has attained stability
>>
>> This would be implemented for the following endpoints/subsystems:
>>
>> - Undertow will hold requests until the deployment is done (so if you
>> try and load a page while deployment is happening it could be a bit of a
>> wait)
>> - Remote EJB will hold requests until deployment is done
>> - mod_cluster will not send availability messages until deployment is done
>
> Isn't this what mod_cluster does on a per-deployment basis anyway? The
> basic idea of mod_cluster is the LB isn't notified the context is
> available on a backend server until it's....available.
 
True, but not everyone is using mod_cluster.
 
>
>> - JMS will delay message delivery until deployment is done
>> - EJB persistent timers will not fire until deployment is done
>> - Possibly some other cases I can't think of right now
>>
>> One thing I am not really sure about is if we need a configuration
>> switch for hold/reject behavior. e.g. for Undertow the request holding
>> behavior is very developer friendly, as it means they can just hit
>> refresh in their browser and as soon as the redeployment is done the
>> page will display, however I am worried that it might not be ideal for
>> load balancers that may prefer a quick error response that could then be
>> attempted on another node (although if mod_cluster is not sending out
>> availability till the deployment is 100% complete this may not be a big
>> deal).
>>
>> If you want to see this in action I have a very simple PR at [3] that
>> enables this for Undertow at server boot.
>>
>> Thoughts?
>>
>> Stuart
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
 
 
------------------------------
 
Message: 6
Date: Thu, 21 Apr 2016 15:39:56 -0500
From: Brian Stansberry <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
To: John Doyle <[hidden email]>
Message-ID: <[hidden email]>
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
> <[hidden email]> 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
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
 
 
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
 
 
------------------------------
 
Message: 7
Date: Thu, 21 Apr 2016 22:59:54 +0000
From: Stuart Douglas <[hidden email]>
Subject: Re: [wildfly-dev] Graceful startup
To: Brian Stansberry <[hidden email]>,
Message-ID:
Content-Type: text/plain; charset="utf-8"
 
> > - Undertow will hold requests until the deployment is done (so if you
> > try and load a page while deployment is happening it could be a bit of a
> > wait)
> > - Remote EJB will hold requests until deployment is done
> > - mod_cluster will not send availability messages until deployment is
> done
>
> Isn't this what mod_cluster does on a per-deployment basis anyway? The
> basic idea of mod_cluster is the LB isn't notified the context is
> available on a backend server until it's....available.
>
>
At the moment it is sent when the Undertow service comes up. It is 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...
 
------------------------------
 
_______________________________________________
wildfly-dev mailing list
 
End of wildfly-dev Digest, Vol 37, Issue 9
******************************************
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Heiko Braun
How would suspend/resume be applied in this situation? I think we speak about server startup, right?

On 22 Apr 2016, at 05:00, Stuart Douglas <[hidden email]> wrote:

 If the user really wants reject behavior they can uses suspend/resume to achieve this.



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Graceful startup

Stuart Douglas


On Fri, 22 Apr 2016 at 17:10 Heiko Braun <[hidden email]> wrote:
How would suspend/resume be applied in this situation? I think we speak about server startup, right?

Good point. I was actually thinking about redeploy, but you are right that there is not really any way to apply suspend/resume in this case.

I think a switch between reject/hold may be the best idea then, as there are pros and cons of each.

Stuart
 

On 22 Apr 2016, at 05:00, Stuart Douglas <[hidden email]> wrote:

 If the user really wants reject behavior they can uses suspend/resume to achieve this.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev