[JBoss JIRA] (ELY-1430) WARN logged during server shutdown when Elytron JACC is set
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1430?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev moved WFCORE-3390 to ELY-1430:
--------------------------------------------
Project: WildFly Elytron (was: WildFly Core)
Key: ELY-1430 (was: WFCORE-3390)
Component/s: (was: Security)
Affects Version/s: 1.2.0.Beta8
(was: 3.0.9.Final)
> WARN logged during server shutdown when Elytron JACC is set
> -----------------------------------------------------------
>
> Key: ELY-1430
> URL: https://issues.jboss.org/browse/ELY-1430
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.2.0.Beta8
> Reporter: Ondrej Kotek
> Assignee: Ilia Vassilev
> Priority: Critical
>
> When Elytron JACC policy resource is defined, there is WARN logged during server shutdown:
> {{WARN [org.wildfly.security] (MSC service thread 1-8) ELY08509: Calling any of the Policy.getPermissions() methods is not supported; please see the Java Authorization Contract for Containers (JACC) specification (section "1.4 Requirements", item 1) and the Java SE API specification for the Policy.getPermissions() methods for more information. Instead, use the Policy.implies() method for authorization checking.}}
> This is suspicious behaviour. Customers that monitor logs for warnings have to deal with this. Setting Critical.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-9497) Add clustering externalizers for common JDK abstract classes
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9497?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-9497:
-------------------------------
Description:
A number of JDK objects are common in a web session, where the implementation class is private or unimportant. Our current ObjectTable implementation chooses its externalizer based on the implementation class, so some modifications are required to accept externalizers whose target class is abstract.
e.g. TimeZone, ZoneId, Calendar
was:e.g. TimeZone, ZoneId, Calendar
> Add clustering externalizers for common JDK abstract classes
> ------------------------------------------------------------
>
> Key: WFLY-9497
> URL: https://issues.jboss.org/browse/WFLY-9497
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 12.0.0.Alpha1
>
>
> A number of JDK objects are common in a web session, where the implementation class is private or unimportant. Our current ObjectTable implementation chooses its externalizer based on the implementation class, so some modifications are required to accept externalizers whose target class is abstract.
> e.g. TimeZone, ZoneId, Calendar
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3397) Integrate improved thread pool implementation
by David Lloyd (JIRA)
David Lloyd created WFCORE-3397:
-----------------------------------
Summary: Integrate improved thread pool implementation
Key: WFCORE-3397
URL: https://issues.jboss.org/browse/WFCORE-3397
Project: WildFly Core
Issue Type: Feature Request
Components: CLI, Domain Management, IO, Server, Test Suite
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 4.0.0.Alpha3
Introduce new thread pool implementation with separate core/max size and configurable parameters, and reuse-idle-thread behavior.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-5332) Allow configure max-threads and core-threads independently. Allow idle thread reusage.
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-5332:
---------------------------------
Assignee: David Lloyd (was: Panagiotis Sotiropoulos)
> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
> Key: WFLY-5332
> URL: https://issues.jboss.org/browse/WFLY-5332
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Panagiotis Sotiropoulos
> Assignee: David Lloyd
> Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there. The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new
> thread [up until max-threads]."
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old members doesn't seem to get removed
by Jesper Blomquist (JIRA)
Jesper Blomquist created JGRP-2232:
--------------------------------------
Summary: Using NATIVE_S3_PING old members doesn't seem to get removed
Key: JGRP-2232
URL: https://issues.jboss.org/browse/JGRP-2232
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.7
Environment: Spring Boot / Boxfuse / AWS
Reporter: Jesper Blomquist
Assignee: Bela Ban
Priority: Minor
According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
967 elements:
i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFCORE-3396) Provide certificate authority integration
by Martin Choma (JIRA)
Martin Choma created WFCORE-3396:
------------------------------------
Summary: Provide certificate authority integration
Key: WFCORE-3396
URL: https://issues.jboss.org/browse/WFCORE-3396
Project: WildFly Core
Issue Type: Feature Request
Components: Security
Affects Versions: 4.0.0.Alpha2
Reporter: Martin Choma
Assignee: Darran Lofthouse
Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.
This can simplify administrator work. No need to perform certification renewal routine tasks.
This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.
[1] https://tools.ietf.org/html/draft-ietf-acme-acme-07
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-1903) GRE DSL: Multiline code blocks break the editor
by Toni Rikkola (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1903?page=com.atlassian.jira.plugi... ]
Toni Rikkola updated DROOLS-1903:
---------------------------------
Sprint: 2017 Week 34-35, 2017 Week 43-44 (was: 2017 Week 34-35)
> GRE DSL: Multiline code blocks break the editor
> -----------------------------------------------
>
> Key: DROOLS-1903
> URL: https://issues.jboss.org/browse/DROOLS-1903
> Project: Drools
> Issue Type: Bug
> Components: Guided Rule Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Labels: support
>
> Rules where the generated DRL has brackets break the editor if DSL is in use.
> When DSL is in use the normal DRL lines are marked "special" with the > character so that the DSL detection can ignore them. Once DSL has been replaced with DRL we remove the > characters.
> The codes merge brackets to the same line before the > characters are removed. This leaves > characters to the end code and they break the parser. The entire rule editor then defaults to showing the raw file data that contains a > character for each line.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months