[JBoss JIRA] (WFCORE-1541) ModelControllerClientConfiguration.Builder should provide better control over the executor
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1541?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1541:
----------------------------------------
Assignee: Brian Stansberry
> ModelControllerClientConfiguration.Builder should provide better control over the executor
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-1541
> URL: https://issues.jboss.org/browse/WFCORE-1541
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> The ModelControllerClientConfiguration provides an ExecutorService but the builder does not provide a way to set it. And then the impl has a field to toggle whether the executor is shut down by the close() method, but there is no way to set that field. It always ends up 'true'.
> Proposal:
> 1) Add setters to the builder for both the executor and the shutdown field.
> 2) Default for the shutdown field depends on whether the executor got set. If the user passes in an executor, then we assume they control its lifecycle. If they don't and the standard one gets used, then closing the config should close the executor. And if the user doesn't like those defaults they can set the flag themselves.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1541) ModelControllerClientConfiguration.Builder should provide better control over the executor
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1541:
----------------------------------------
Summary: ModelControllerClientConfiguration.Builder should provide better control over the executor
Key: WFCORE-1541
URL: https://issues.jboss.org/browse/WFCORE-1541
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Priority: Minor
The ModelControllerClientConfiguration provides an ExecutorService but the builder does not provide a way to set it. And then the impl has a field to toggle whether the executor is shut down by the close() method, but there is no way to set that field. It always ends up 'true'.
Proposal:
1) Add setters to the builder for both the executor and the shutdown field.
2) Default for the shutdown field depends on whether the executor got set. If the user passes in an executor, then we assume they control its lifecycle. If they don't and the standard one gets used, then closing the config should close the executor. And if the user doesn't like those defaults they can set the flag themselves.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1540) Expose capability registry via mgmt api
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-1540:
-----------------------------------
Summary: Expose capability registry via mgmt api
Key: WFCORE-1540
URL: https://issues.jboss.org/browse/WFCORE-1540
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
add /core-service=capability-registry
that has possible-capabilities and "capabilities" as attributes
add also operations for querying that info
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1539) Consider doing management remoting write interaction using a fixed size pool
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1539?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1539:
-------------------------------------
Description:
Since the work on WFLY-3090 a lot of the management layer's work of writing to remoting has been done asynchronously to the calling thread using the thread pool associated with the ManagementRequestContext. In practice this pool is the unbounded HostControllerExecutorService or ServerExecutorService. But unbounded queues may be inefficient for how some caching strategies work, so using a fixed pool for this may be better. See WFCORE-1528 for a caching problem in undertow, which we don't believe remoting has, but which is the kind of fragility we want to avoid.
The following are the uses of executors with the ManagementRequestContext. The first two methods use the executor associated with the MRC, i.e. HostControllerExecutorService or ServerExecutorService. The 3rd method the caller provides an executor. The items marked with 2 stars are unusual in some way but probably ok for a fixed pool, those with 4 stars we definitely don't want a fixed pool, and 3 stars need a bit more thought. The others should be ok with a fixed pool.
{code}
executeAsync(AsyncTask task, boolean cancellable)
CancelAsyncRequestHandler L330 -- async sends the response
ModelControllerClientOperationHandler.CompletedCallback L287 -- sends final response
TransactionalProtocolClientImpl.ExecuteRequest L161 -- sends the main *request* async
TransactionalProtocolClientImpl.CompleteTxRequest L265 -- sends the commit/rollback *request* async
TransactionalProtocolOperationHandler L602 -- multiple uses
ExecuteRequestContext L557 -- completed
ExecuteRequestContext L420 -- failed
ExecuteRequestContext L532 -- failed
ExecuteRequestContext L467 -- prepared
** TransactionalProtocolOperationHandler.ExecuteRequestContext L578 -- actually does the cancel
** HostControllerConnection.ServerReconnectRequest L311 -- calls done on ResultHandler (I see no reason this needs to be async)
executeAsync(final AsyncTask<A> task)
ResponseAttachmentInputStreamSupport.AbstractAttachmentHandler L275 -- reads stream, writes out to remoting
TransactionalProtocolClientImpl.ReadAttachmentInputStreamRequestHandler L335 -- reads stream, writes out to remoting
TransactionalProtocolOperationHandler.ExecuteRequestHandler L170 -- executes the request
AbstractModelControllerClient.ReadAttachmentInputStreamRequestHandler L211 -- reads stream, writes out to remoting
RemoteFileRequestAndHandler L152 -- writes the response
**** RemoteDomainConnection.HostControllerConnectRequest L385 -- resolve subsystem versions, send to DC
**** RemoteDomainConnection.RegisterSubsystemsRequest L450 -- apply domain model (which surely takes the lock)
**** ServerToHostProtocolHandler.ServerReconnectRequestHandler L262 -- takes lock! calls ServerInventory.serverReconnected
*** ServerToHostProtocolHandler.ServerStartedHandler L335 -- invokes the server inventory, serverStarted/StartFailed
executeAsync(final AsyncTask<A> task, Executor executor)
ModelControllerClientOperationHandler.ExecuteRequestHandler L142 -- execute request using a fixed size pool
RemoteFileRequestAndHandler L154 -- read and write the file using an executor provided to the constructor
this executor is null except on a DC where it is the HostControllerExecutorService
**** HostControllerRegistrationHandler.InitiateRegistrationHandler L231 -- registration using HostControllerExecutorService
**** ServerToHostProtocolHandler.ServerRegistrationRequestHandler L177 -- server reg using an Executors.singleThreadExecutor
{code}
Given the preponderance of cases where a fixed pool is ok, if we choose to do this task perhaps the simple solution is to make the MRC pool fixed by default and for cases where that is inappropriate provide the caller with a ref to HostControllerExecutorService or ServerExecutorService and lets them pass it in to the MRC method as a param.
was:
Since the work on WFLY-3090 a lot of the management layer's work of writing to remoting has been done asynchronously to the calling thread using the thread pool associated with the ManagementRequestContext. In practice this pool is the unbounded HostControllerExecutorService or ServerExecutorService. But unbounded queues may be inefficient for how some caching strategies work, so using a fixed pool for this may be better. See WFCORE-1528 for a caching problem in undertow, which we don't believe remoting has, but which is the kind of fragility we want to avoid.
The following are the uses of executors with the ManagementRequestContext. The first two methods use the executor associated with the MRC, i.e. HostControllerExecutorService or ServerExecutorService. The 3rd method the caller provides an executor. The items marked with 2 stars are unusual in some way but probably ok for a fixed pool, those with 4 stars we definitely don't want a fixed pool, and 3 stars need a bit more thought. The others should be ok with a fixed pool.
executeAsync(AsyncTask task, boolean cancellable)
CancelAsyncRequestHandler L330 -- async sends the response
ModelControllerClientOperationHandler.CompletedCallback L287 -- sends final response
TransactionalProtocolClientImpl.ExecuteRequest L161 -- sends the main *request* async
TransactionalProtocolClientImpl.CompleteTxRequest L265 -- sends the commit/rollback *request* async
TransactionalProtocolOperationHandler L602 -- multiple uses
ExecuteRequestContext L557 -- completed
ExecuteRequestContext L420 -- failed
ExecuteRequestContext L532 -- failed
ExecuteRequestContext L467 -- prepared
** TransactionalProtocolOperationHandler.ExecuteRequestContext L578 -- actually does the cancel
** HostControllerConnection.ServerReconnectRequest L311 -- calls done on ResultHandler (I see no reason this needs to be async)
executeAsync(final AsyncTask<A> task)
ResponseAttachmentInputStreamSupport.AbstractAttachmentHandler L275 -- reads stream, writes out to remoting
TransactionalProtocolClientImpl.ReadAttachmentInputStreamRequestHandler L335 -- reads stream, writes out to remoting
TransactionalProtocolOperationHandler.ExecuteRequestHandler L170 -- executes the request
AbstractModelControllerClient.ReadAttachmentInputStreamRequestHandler L211 -- reads stream, writes out to remoting
RemoteFileRequestAndHandler L152 -- writes the response
**** RemoteDomainConnection.HostControllerConnectRequest L385 -- resolve subsystem versions, send to DC
**** RemoteDomainConnection.RegisterSubsystemsRequest L450 -- apply domain model (which surely takes the lock)
**** ServerToHostProtocolHandler.ServerReconnectRequestHandler L262 -- takes lock! calls ServerInventory.serverReconnected
*** ServerToHostProtocolHandler.ServerStartedHandler L335 -- invokes the server inventory, serverStarted/StartFailed
executeAsync(final AsyncTask<A> task, Executor executor)
ModelControllerClientOperationHandler.ExecuteRequestHandler L142 -- execute request using a fixed size pool
RemoteFileRequestAndHandler L154 -- read and write the file using an executor provided to the constructor
this executor is null except on a DC where it is the HostControllerExecutorService
**** HostControllerRegistrationHandler.InitiateRegistrationHandler L231 -- registration using HostControllerExecutorService
**** ServerToHostProtocolHandler.ServerRegistrationRequestHandler L177 -- server reg using an Executors.singleThreadExecutor
Given the propenderance of cases where a fixed pool is ok, if we choose to do this task perhaps the simple solution is to make the MRC pool fixed by default and for cases where that is inappropriate provide the caller with a ref to HostControllerExecutorService or ServerExecutorService and lets them pass it in to the MRC method as a param.
> Consider doing management remoting write interaction using a fixed size pool
> ----------------------------------------------------------------------------
>
> Key: WFCORE-1539
> URL: https://issues.jboss.org/browse/WFCORE-1539
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Since the work on WFLY-3090 a lot of the management layer's work of writing to remoting has been done asynchronously to the calling thread using the thread pool associated with the ManagementRequestContext. In practice this pool is the unbounded HostControllerExecutorService or ServerExecutorService. But unbounded queues may be inefficient for how some caching strategies work, so using a fixed pool for this may be better. See WFCORE-1528 for a caching problem in undertow, which we don't believe remoting has, but which is the kind of fragility we want to avoid.
> The following are the uses of executors with the ManagementRequestContext. The first two methods use the executor associated with the MRC, i.e. HostControllerExecutorService or ServerExecutorService. The 3rd method the caller provides an executor. The items marked with 2 stars are unusual in some way but probably ok for a fixed pool, those with 4 stars we definitely don't want a fixed pool, and 3 stars need a bit more thought. The others should be ok with a fixed pool.
> {code}
> executeAsync(AsyncTask task, boolean cancellable)
> CancelAsyncRequestHandler L330 -- async sends the response
> ModelControllerClientOperationHandler.CompletedCallback L287 -- sends final response
> TransactionalProtocolClientImpl.ExecuteRequest L161 -- sends the main *request* async
> TransactionalProtocolClientImpl.CompleteTxRequest L265 -- sends the commit/rollback *request* async
> TransactionalProtocolOperationHandler L602 -- multiple uses
> ExecuteRequestContext L557 -- completed
> ExecuteRequestContext L420 -- failed
> ExecuteRequestContext L532 -- failed
> ExecuteRequestContext L467 -- prepared
> ** TransactionalProtocolOperationHandler.ExecuteRequestContext L578 -- actually does the cancel
> ** HostControllerConnection.ServerReconnectRequest L311 -- calls done on ResultHandler (I see no reason this needs to be async)
> executeAsync(final AsyncTask<A> task)
> ResponseAttachmentInputStreamSupport.AbstractAttachmentHandler L275 -- reads stream, writes out to remoting
> TransactionalProtocolClientImpl.ReadAttachmentInputStreamRequestHandler L335 -- reads stream, writes out to remoting
> TransactionalProtocolOperationHandler.ExecuteRequestHandler L170 -- executes the request
> AbstractModelControllerClient.ReadAttachmentInputStreamRequestHandler L211 -- reads stream, writes out to remoting
> RemoteFileRequestAndHandler L152 -- writes the response
> **** RemoteDomainConnection.HostControllerConnectRequest L385 -- resolve subsystem versions, send to DC
> **** RemoteDomainConnection.RegisterSubsystemsRequest L450 -- apply domain model (which surely takes the lock)
> **** ServerToHostProtocolHandler.ServerReconnectRequestHandler L262 -- takes lock! calls ServerInventory.serverReconnected
> *** ServerToHostProtocolHandler.ServerStartedHandler L335 -- invokes the server inventory, serverStarted/StartFailed
> executeAsync(final AsyncTask<A> task, Executor executor)
> ModelControllerClientOperationHandler.ExecuteRequestHandler L142 -- execute request using a fixed size pool
> RemoteFileRequestAndHandler L154 -- read and write the file using an executor provided to the constructor
> this executor is null except on a DC where it is the HostControllerExecutorService
> **** HostControllerRegistrationHandler.InitiateRegistrationHandler L231 -- registration using HostControllerExecutorService
> **** ServerToHostProtocolHandler.ServerRegistrationRequestHandler L177 -- server reg using an Executors.singleThreadExecutor
> {code}
> Given the preponderance of cases where a fixed pool is ok, if we choose to do this task perhaps the simple solution is to make the MRC pool fixed by default and for cases where that is inappropriate provide the caller with a ref to HostControllerExecutorService or ServerExecutorService and lets them pass it in to the MRC method as a param.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1539) Consider doing management remoting write interaction using a fixed size pool
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1539:
----------------------------------------
Summary: Consider doing management remoting write interaction using a fixed size pool
Key: WFCORE-1539
URL: https://issues.jboss.org/browse/WFCORE-1539
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Since the work on WFLY-3090 a lot of the management layer's work of writing to remoting has been done asynchronously to the calling thread using the thread pool associated with the ManagementRequestContext. In practice this pool is the unbounded HostControllerExecutorService or ServerExecutorService. But unbounded queues may be inefficient for how some caching strategies work, so using a fixed pool for this may be better. See WFCORE-1528 for a caching problem in undertow, which we don't believe remoting has, but which is the kind of fragility we want to avoid.
The following are the uses of executors with the ManagementRequestContext. The first two methods use the executor associated with the MRC, i.e. HostControllerExecutorService or ServerExecutorService. The 3rd method the caller provides an executor. The items marked with 2 stars are unusual in some way but probably ok for a fixed pool, those with 4 stars we definitely don't want a fixed pool, and 3 stars need a bit more thought. The others should be ok with a fixed pool.
executeAsync(AsyncTask task, boolean cancellable)
CancelAsyncRequestHandler L330 -- async sends the response
ModelControllerClientOperationHandler.CompletedCallback L287 -- sends final response
TransactionalProtocolClientImpl.ExecuteRequest L161 -- sends the main *request* async
TransactionalProtocolClientImpl.CompleteTxRequest L265 -- sends the commit/rollback *request* async
TransactionalProtocolOperationHandler L602 -- multiple uses
ExecuteRequestContext L557 -- completed
ExecuteRequestContext L420 -- failed
ExecuteRequestContext L532 -- failed
ExecuteRequestContext L467 -- prepared
** TransactionalProtocolOperationHandler.ExecuteRequestContext L578 -- actually does the cancel
** HostControllerConnection.ServerReconnectRequest L311 -- calls done on ResultHandler (I see no reason this needs to be async)
executeAsync(final AsyncTask<A> task)
ResponseAttachmentInputStreamSupport.AbstractAttachmentHandler L275 -- reads stream, writes out to remoting
TransactionalProtocolClientImpl.ReadAttachmentInputStreamRequestHandler L335 -- reads stream, writes out to remoting
TransactionalProtocolOperationHandler.ExecuteRequestHandler L170 -- executes the request
AbstractModelControllerClient.ReadAttachmentInputStreamRequestHandler L211 -- reads stream, writes out to remoting
RemoteFileRequestAndHandler L152 -- writes the response
**** RemoteDomainConnection.HostControllerConnectRequest L385 -- resolve subsystem versions, send to DC
**** RemoteDomainConnection.RegisterSubsystemsRequest L450 -- apply domain model (which surely takes the lock)
**** ServerToHostProtocolHandler.ServerReconnectRequestHandler L262 -- takes lock! calls ServerInventory.serverReconnected
*** ServerToHostProtocolHandler.ServerStartedHandler L335 -- invokes the server inventory, serverStarted/StartFailed
executeAsync(final AsyncTask<A> task, Executor executor)
ModelControllerClientOperationHandler.ExecuteRequestHandler L142 -- execute request using a fixed size pool
RemoteFileRequestAndHandler L154 -- read and write the file using an executor provided to the constructor
this executor is null except on a DC where it is the HostControllerExecutorService
**** HostControllerRegistrationHandler.InitiateRegistrationHandler L231 -- registration using HostControllerExecutorService
**** ServerToHostProtocolHandler.ServerRegistrationRequestHandler L177 -- server reg using an Executors.singleThreadExecutor
Given the propenderance of cases where a fixed pool is ok, if we choose to do this task perhaps the simple solution is to make the MRC pool fixed by default and for cases where that is inappropriate provide the caller with a ref to HostControllerExecutorService or ServerExecutorService and lets them pass it in to the MRC method as a param.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1523) RestartParentResourceRemoveHandler should fail when removing non-existing resources
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1523?page=com.atlassian.jira.plugi... ]
Bartosz Spyrko-Śmietanko updated WFCORE-1523:
---------------------------------------------
Summary: RestartParentResourceRemoveHandler should fail when removing non-existing resources (was: Removing of non-existent resource finishes with outcome success)
> RestartParentResourceRemoveHandler should fail when removing non-existing resources
> -----------------------------------------------------------------------------------
>
> Key: WFCORE-1523
> URL: https://issues.jboss.org/browse/WFCORE-1523
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.1.0.Final
> Reporter: Ondrej Lukas
> Assignee: Bartosz Spyrko-Śmietanko
> Priority: Minor
> Labels: 2.2
> Fix For: 3.0.0.Alpha1
>
>
> In case when non-existent policy-module is removed through Management CLI, operation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months