[JBoss JIRA] (WFCORE-184) Handle external requests during boot with a failure that indicates non-readiness
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-184?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-184:
------------------------------------
Summary: Handle external requests during boot with a failure that indicates non-readiness (was: Handle external requests during boot with a NoSuchResourceException)
> Handle external requests during boot with a failure that indicates non-readiness
> --------------------------------------------------------------------------------
>
> Key: WFCORE-184
> URL: https://issues.jboss.org/browse/WFCORE-184
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 1.0.0.Alpha11
>
>
> Lock out external callers during boot by immediately replying as if the root resource does not exist.
> This will not break callers like the ARQ containers that poll in a loop waiting for the root 'server-state' attribute to be 'RUNNING' as those callers already need to have logic for dealing with the failures that can occur during those reads.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7462:
----------------------------------------
+1 I think the definitions need to be double checked but you are correct, those should have already been picked up as a duplicate definition of the same capability.
> Do not log common CLI failures for Elytron to server log
> --------------------------------------------------------
>
> Key: WFLY-7462
> URL: https://issues.jboss.org/browse/WFLY-7462
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: user_experience
>
> Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means:
> * trying to add duplicate service -> ERROR in server log
> * missing required attribute of any resource attribute in CLI command -> ERROR in server log
> * missing capability -> ERROR in server log
> * ...
> Some reasons why these logs should not be logged to server log:
> * Adding useless messages to server log.
> * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing.
> These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7462) Do not log common CLI failures for Elytron to server log
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7462?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7462:
----------------------------------------
Probably I messed something up when I tried to reproduce. It worked fine for me. I used the embed-server; maybe I forgot to specify --admin-only=false. Sorry for wasting your time.
Re: the DuplicateServiceException, I do expect that one to appear in the log and there's nothing particular to elytron about that. Arguably it would be better if it didn't, but I don't want to just suppress those. We don't suppress exceptions in Stage.RUNTIME as those mean something has happened while trying to change the runtime, which may have had negative effects on the runtime. (A failure in Stage.MODEL just means the op fails, the op's copy of the model never gets published, and no one but the caller is affected.) Better than suppressing Stage.RUNTIME issues like DuplicateServiceException is to bit by bit make it harder for that to occur without it being detected before getting to the MSC level. See for example WFCORE-1106 for an approach to avoiding that in cases where it occurs because the user ignored a reload-required.
I think the DuplicateServiceException case is less serious than the others though. Getting that requires doing something fairly unusual.
[~dlofthouse] re the ldap-realm vs properties-realm name duplication leading to the DuplicateServiceException (see the last example in Ondrej's last post): isn't that a case of two resources adding the same capability? If so I'd expect that to fail in Stage.MODEL, before MSC gets involved.
> Do not log common CLI failures for Elytron to server log
> --------------------------------------------------------
>
> Key: WFLY-7462
> URL: https://issues.jboss.org/browse/WFLY-7462
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: user_experience
>
> Almost every common CLI command failure from Elytron subsystem is logged as ERROR to server log. For example this means:
> * trying to add duplicate service -> ERROR in server log
> * missing required attribute of any resource attribute in CLI command -> ERROR in server log
> * missing capability -> ERROR in server log
> * ...
> Some reasons why these logs should not be logged to server log:
> * Adding useless messages to server log.
> * This is inconsistent with other subsystems (e.g. PicketBox). It can be confusing.
> These common CLI command failures should be removed from the log, or logged on low level (i.e. DEBUG)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7219) Wrong description of missing target-name in simple-permission-mapper
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/WFLY-7219?page=com.atlassian.jira.plugin.... ]
Ilia Vassilev commented on WFLY-7219:
-------------------------------------
[~honza889] One way of knowing if "target-name" or/and "action" are required in the subsystem is to get the number of arguments from the permission class by implementing similar logic like PermissionUtil.createPermission or expose this functionality from Elytron. When we catch the exception in Elytron Subsystem we can throw a specific message if:
1. twoArg: "target-name" and "action" are both required
2. oneArg: "target-name" is required, "action" can be null.
3. noArgs: "target-name" and "action" are optional and can be null
We already check if class-name is null.
> Wrong description of missing target-name in simple-permission-mapper
> --------------------------------------------------------------------
>
> Key: WFLY-7219
> URL: https://issues.jboss.org/browse/WFLY-7219
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Labels: user_experience
> Fix For: 11.0.0.Alpha1
>
>
> In case when simple-permission-mapper cannot be added through CLI command due to missing target-name attribute, then IllegalArgumentException with wrong description is thrown. It says: "Parameter '*name*' may not be null". It should be "Parameter '*target-name*' may not be null".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7492) Value of parameter "restart-required" for principal-decoders attribute does not match reality for concatenating-principal-decoder in CLI (Elytron subsystem)
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7492?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-6924 to WFLY-7492:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7492 (was: JBEAP-6924)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: User Experience)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR7)
> Value of parameter "restart-required" for principal-decoders attribute does not match reality for concatenating-principal-decoder in CLI (Elytron subsystem)
> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7492
> URL: https://issues.jboss.org/browse/WFLY-7492
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> {{principal-decoders}} attribute of {{concatenating-principal-decoder}} defines in its description that there is not necessary to do {{reload}} or {{restart}}. But reality is different. Trying to change such attributes you are informed that {{reload}} is necessary.
> The attribute is defined as {{"restart-required" => "no-services"}}, see {{/subsystem=elytron/concatenating-principal-decoder=concatPrincDecoder:read-resource-description}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFLY-7491) joiner attribute of concatenating-principal-decoder (Elytron subsystem) is marked as nillable but can not be
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7491?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-6923 to WFLY-7491:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7491 (was: JBEAP-6923)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
(was: User Experience)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR7)
> joiner attribute of concatenating-principal-decoder (Elytron subsystem) is marked as nillable but can not be
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7491
> URL: https://issues.jboss.org/browse/WFLY-7491
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Kotek
> Assignee: Darran Lofthouse
> Labels: user_experience
>
> *Issue description:*
> After having undefined the {{joiner}} attribute of {{concatenating-principal-decoder}} in Elytron subsystem, the server does not start. The {{joiner}} attribute is declared as {{"nillable" => true}} in CLI, but can not be -- see _Steps to Reproce_ that results in
> {noformat}
> 14:50:29,357 ERROR [org.jboss.as.controller] (Controller Boot Thread)
> OPVDX001: Validation error in standalone-elytron.xml ===========================
> 346: <permission class-name="org.wildfly.security.auth.permission.LoginPermission"/>
> 347: </constant-permission-mapper>
> 348: <concatenating-principal-decoder name="concatPrincDecoder">
> ^^^^ 'concatenating-principal-decoder' is missing one or more required attributes
> All of the following are required: joiner
> 349: <principal-decoder name="constPrincDecoder"/>
> 350: <principal-decoder name="constPrincDecoder"/>
> 351: </concatenating-principal-decoder>
> The underlying error message was:
> > ParseError at [row,col]:[348,17]
> > Message: WFLYCTL0133: Missing required attribute(s): joiner
> ================================================================================
> 14:50:29,357 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:143)
> at org.jboss.as.server.ServerService.boot(ServerService.java:355)
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:302)
> at java.lang.Thread.run(Thread.java:745)
> 14:50:29,358 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {noformat}
> The {{joiner}} attribute has {{use="required"}} in _wildfly-elytron_1_0.xsd_.
> *Suggestions for improvement:*
> In case it makes sense to have no joiner, the joiner should not be required. Otherwise, the {{joiner}} attribute should be declared as {{"nillable" => false}} in CLI.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months
[JBoss JIRA] (WFCORE-1934) Make maximumPoolSize of ServerService Thread Pool configurable
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1934:
------------------------------------------
This thread pool is meant for handling blocking tasks. A fixed size pool with an unbounded queue is not semantically equivalent for a pool used in this way.
> Make maximumPoolSize of ServerService Thread Pool configurable
> --------------------------------------------------------------
>
> Key: WFCORE-1934
> URL: https://issues.jboss.org/browse/WFCORE-1934
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.2.0.Final
> Reporter: Masafumi Miura
> Assignee: Jason Greene
> Attachments: ServerServiceThreadPool_ejb_startup_singleton.zip, ServerServiceThreadPool_persistence_unit.zip
>
>
> Provide a way to configure {{maximumPoolSize}} of {{ServerService Thread Pool}}. It defaults to {{Integer.MAX_VALUE}} and it's unable to be changed in the current implementation:
>
> {quote}
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> {code}
> 446 public synchronized void start(StartContext context) throws StartException {
> 447 executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 20L, TimeUnit.SECONDS,
> 448 new SynchronousQueue<Runnable>(), threadFactory);
> 449 }
> {code}
> {quote}
> Though the threads will disappear after 20 seconds of finishing a task, ulimit ({{nproc}}, max user processes) has a possibility to run out depending on deployed applications. For example, an application coming with many {{<persistence-unit>}} entries in {{persistence.xml}} or a lot of @Startup @Singleton EJB can cause spawning a lot of {{ServerService Thread Pool}} thread.
> Even if ulimit can be configurable and it is recommended to be tuned in a production environment, making {{maximumPoolSize}} of {{ServerService Thread Pool}} configurable would be helpful.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 8 months