November 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-724) Add support for matching by abstract type

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-724?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-724: --------------------------------- Fix Version/s: 1.1.0.Beta14 (was: 1.1.0.Beta13) > Add support for matching by abstract type > ----------------------------------------- > > Key: ELY-724 > URL: https://issues.jboss.org/browse/ELY-724 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta14 > > > Match by abstract type, which is a logical supplement to a URI that indicates the encompassed service type (for example, ejb, jmx, jndi, etc.). > Abstract types also have an authority. For example the authority for the type "ejb" is "jboss". -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-722) Move callback handler interactions to a common base class for HTTP mechanisms, .

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-722?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-722: --------------------------------- Fix Version/s: 1.1.0.Beta14 (was: 1.1.0.Beta13) > Move callback handler interactions to a common base class for HTTP mechanisms,. > ------------------------------------------------------------------------------- > > Key: ELY-722 > URL: https://issues.jboss.org/browse/ELY-722 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta14 > > > This is to follow a similar pattern as is used for the SASL mechanisms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-681) Hide private packages from generated javadoc.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-681?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-681: --------------------------------- Fix Version/s: 1.1.0.Beta14 (was: 1.1.0.Beta13) > Hide private packages from generated javadoc. > --------------------------------------------- > > Key: ELY-681 > URL: https://issues.jboss.org/browse/ELY-681 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.Beta14 > > > We may want two profiles so we can generate a full javadoc and a 'public' javadoc. > The 'public' javadoc should be the default one generated and should exclude the following packages: - > org.wildfly.security._private > org.wildfly.security.asn1 > org.wildfly.security.auth.realm > org.wildfly.security.auth.realm.* > org.wildfly.security.authz.jacc > org.wildfly.security.credential.store.impl > org.wildfly.security.security.digest > org.wildfly.security.http.impl > org.wildfly.security.security.keystore > org.wildfly.security.mechanism.oauth2 > org.wildfly.security.mechanism.scram > org.wildfly.security.password.impl > org.wildfly.security.password.util > org.wildfly.security.pem > org.wildfly.security.sasl > org.wildfly.security.sasl.* (Except util) > org.wildfly.security.util > org.wildfly.security.util_private > org.wildfly.security.x500 > org.wildfly.security.x500.cert -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-714) Release WildFly Elytron 1.1.0.Beta13

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-714?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-714. ---------------------------------- Resolution: Done > Release WildFly Elytron 1.1.0.Beta13 > ------------------------------------ > > Key: ELY-714 > URL: https://issues.jboss.org/browse/ELY-714 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta13 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7509) Graceful shutdown support for WebHost deployments

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7509: ------------------------------------ Summary: Graceful shutdown support for WebHost deployments Key: WFLY-7509 URL: https://issues.jboss.org/browse/WFLY-7509 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1934) Make number of thread size for 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: ------------------------------------------ Option 2 is not a valid option, as tasks handed off to this queue must either be executed or the handoff must fail. The main uses of the pool count on this. RejectedExecutionException is another form of failure, preferable in the abstract to an OOME, but a lot of uses of this method would need to be adapted to account for this possibility. And some of them I don't think really could be properly adapted. I don't believe we should support making this configurable, as the end user is unlikely to know how to properly configure it. For scenarios like your reproducer, this is why you test things in staging -- to ensure that you have given your server adequate resources for the application you are deploying. > Make number of thread size for 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 and "java.lang.OutOfMemoryError: unable to create new native thread" would occur 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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1934) Make number of thread size for ServerService Thread Pool configurable

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFCORE-1934: ----------------------------------- Summary: Make number of thread size for ServerService Thread Pool configurable (was: Make maximumPoolSize of ServerService Thread Pool configurable) > Make number of thread size for 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 and "java.lang.OutOfMemoryError: unable to create new native thread" would occur 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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1934) Make maximumPoolSize of ServerService Thread Pool configurable

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi... ] Masafumi Miura updated WFCORE-1934: ----------------------------------- Description: 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 and "java.lang.OutOfMemoryError: unable to create new native thread" would occur 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. was: 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. > 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 and "java.lang.OutOfMemoryError: unable to create new native thread" would occur 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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1934) Make maximumPoolSize of ServerService Thread Pool configurable

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1934?page=com.atlassian.jira.plugi... ] Masafumi Miura commented on WFCORE-1934: ---------------------------------------- Yes, it's not semantically equivalent to the default behavior... As far as I read the API documentation of [ThreadPoolExecutor|https://docs.oracle.com/javase/8/docs/api/java/util/co...], there's three options for thread queuing strategies: 1. An unlimited size pool with direct handoffs (SynchronousQueue) 2. A fixed finite size pool with an unbounded queue (LinkedBlockingQueue) 3. A finite max size pool with a bounded queue (ArrayBlockingQueue) (Or a finite max size pool with direct handoffs. but this would be undesirable option.) If I understand correctly, a strategy of the current implementation is option 1. And I thought it's hard to controll how many tasks are executed concurrently, so I thought option 2 (a fixed size pool with an unbounded queue) is better than others when we added a upper limit for the number of the thread pool. (We would face RejectedExecutionException when tasks overflows max pool size and queue, if we select option 3 (or a finite max size pool with direct handoffs)). Please feel free to point out if I'm misunderstand anything. Also please suggest a better idea for this if you agree to add a upper limit for the number of this thread pool. > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-7285) Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7285?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-7285: ----------------------------------- Affects Version/s: (was: 11.0.0.Alpha1) > Elytron - inconsistency between DMR and XSD representation of simple-permission-mapper > -------------------------------------------------------------------------------------- > > Key: WFLY-7285 > URL: https://issues.jboss.org/browse/WFLY-7285 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Optional > Labels: user_experience > Fix For: 11.0.0.Alpha1 > > > There are inconsistencies between DMR and XSD representation of {{simple-permission-mapper}}. > According to XSD both {{permission-mapping}} [1] and its inner {{permission}} [2] must occur at least one times in {{simple-permission-mapper}}. According to DMR they are {{"nillable" => true}}. This should be unified. > [1] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... > [2] https://github.com/wildfly-security/elytron-subsystem/blob/82a3cfb2c1c7c8... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2016