June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2171) New bundler with max_bundle_size for each destination

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2171?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2171: -------------------------------- AlternatingBundler has much worse perf than TransferQueueBundler: ca. half of TQB (20'000 resq/sec/node versus 40'000). The average length of a batch was 2.6 (in my prelim tests) *not* counting single messages. Let's try AlternatingQueuingBundler (alternative 2) now... the queue length need to be configurable. > New bundler with max_bundle_size for each destination > ----------------------------------------------------- > > Key: JGRP-2171 > URL: https://issues.jboss.org/browse/JGRP-2171 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.4 > > > The current bundlers queue all messages and when the total size of all messages for all destinations would exceed {{max_bundle_size}}, message batches for each destination are sent. > This negatively affects latency-sensitive applications, e.g. when we have a queue such as this: {{A B B C B B D B B}}, then the message for A has to wait until either the queue is full ({{max_bundle_size exceeded}}), or no more messages are received (and then we send the batches anyway). > The goal is to write a new bundler which keeps a count for _each destination_ and sends batches to different destinations sooner. Also introduce a counter {{num_flips}} (find a better name!), which determines when a message batch is to be sent. > This counter is decremented when a message to be sent has a destination that's different from the previous destination. When the counter is 0, we send the batch to the previous destination(s). > We have a main queue, into which the senders write, and a runner thread (same as {{run()}} in TransferQueueBundler), which continually removes messages from the main queue and inserts them into queues for each destination. > So 1 main queue and 1 queue for each destination. > h4. Example: > * {{num_flips}} is 2 > * A message for A is sent, added to the main queue and removed by the runner. It is queued in A's queue > * Another message for A is sent. Also queued (A's queue: {{A A}}) > * A message to B is sent: A's {{num_flips}} is now 1. A's queue is {{A A}}, B's queue is {{B}} > * Another message to A is sent. This resets A's {{num_flips}} to 2, B's {{num_flips}} is now 1 > * 2 messages to C are sent. This causes {{num_flips}} for A and B to be 0, so the batches to A (with 3 msgs) and B (1 msg) are also sent > * No more messages are received, so the batch to C is also sent > The value of {{num_flips}} should be computed as the rolling (weighted) average of the number of *adjacent messages to the same destination*. It is maintained for each destination separately (probably in the queue for that destination). > h4. Misc > * Should the sending of batches be delegated to a thread pool? > * Should the senders add their messages directly to the destination queues instead of the main queue? That would result in less contention on the main queue, but it would also require 1 thread per destination queue, which creates too many threads... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8919) Elytron, remove case-sensistive attribute from security realm configurations

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-8919?page=com.atlassian.jira.plugin.... ] Yeray Borges updated WFLY-8919: ------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly-core/pull/2499) > Elytron, remove case-sensistive attribute from security realm configurations > ---------------------------------------------------------------------------- > > Key: WFLY-8919 > URL: https://issues.jboss.org/browse/WFLY-8919 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Blocker > > *Updated descritption:* > Remove case-sensitive attribute from security realm configurations. > As the original filesystem-realm issue JBEAP-8810, which led to introducing the case-sensitive attribute, is fixed, there is no need to have this attribute anymore. It just brings new problems into configuration of the realms. > *Original descritption:* > {{case-sensitive}} attribute with default value to false introduced in DR16 is making problem using kerberos authentication. > {code} > WFLYELY00918: Invalid user name 'jduke(a)JBOSS.ORG' because the realm fileSystemRealm only supports lower case alias names > {code} > It is common to have uppercase realm name in kerberos authentication. User can workaround issue, but it is really unexpected to not work out of box. > * case-sensitive = true > * use principal-transformer 'jduke(a)JBOSS.ORG' -> 'jduke' > {code} > "case-sensitive" => { > "type" => BOOLEAN, > "description" => "Case sensitivity of the properties realm. If case insensitive only lower usernames are allowed.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8919) Elytron, remove case-sensistive attribute from security realm configurations

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFLY-8919?page=com.atlassian.jira.plugin.... ] Yeray Borges moved JBEAP-11469 to WFLY-8919: -------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8919 (was: JBEAP-11469) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: (was: 7.1.0.DR16) > Elytron, remove case-sensistive attribute from security realm configurations > ---------------------------------------------------------------------------- > > Key: WFLY-8919 > URL: https://issues.jboss.org/browse/WFLY-8919 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Blocker > > *Updated descritption:* > Remove case-sensitive attribute from security realm configurations. > As the original filesystem-realm issue JBEAP-8810, which led to introducing the case-sensitive attribute, is fixed, there is no need to have this attribute anymore. It just brings new problems into configuration of the realms. > *Original descritption:* > {{case-sensitive}} attribute with default value to false introduced in DR16 is making problem using kerberos authentication. > {code} > WFLYELY00918: Invalid user name 'jduke(a)JBOSS.ORG' because the realm fileSystemRealm only supports lower case alias names > {code} > It is common to have uppercase realm name in kerberos authentication. User can workaround issue, but it is really unexpected to not work out of box. > * case-sensitive = true > * use principal-transformer 'jduke(a)JBOSS.ORG' -> 'jduke' > {code} > "case-sensitive" => { > "type" => BOOLEAN, > "description" => "Case sensitivity of the properties realm. If case insensitive only lower usernames are allowed.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "default" => false, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2942) Adding credential-reference with non-exist alias to authentication-configuration through CLI results to NPE

by Lin Gao (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2942?page=com.atlassian.jira.plugi... ] Lin Gao reassigned WFCORE-2942: ------------------------------- Assignee: Lin Gao (was: Darran Lofthouse) > Adding credential-reference with non-exist alias to authentication-configuration through CLI results to NPE > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2942 > URL: https://issues.jboss.org/browse/WFCORE-2942 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta23 > Reporter: Ondrej Lukas > Assignee: Lin Gao > Priority: Critical > Labels: user_experience > > When Elytron authentication-configuration is added with credential-reference with non-exist alias through CLI then it results to NullPointerException. > See: > {code} > /subsystem=elytron/credential-store=cs:add(location=cs.jceks,create=true,relative-to=jboss.server.data.dir,credential-reference={clear-text=pass}) > /subsystem=elytron/credential-store=cs:add-alias(alias=exist,secret-value=pass) > /subsystem=elytron/authentication-configuration=cfg1:add(credential-reference={store=cs,alias=exist}) > {"outcome" => "success"} > /subsystem=elytron/authentication-configuration=cfg2:add(credential-reference={store=cs,alias=nonexist}) > { > "outcome" => "failed", > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.authentication-configuration.cfg2" => "Failed to start service > Caused by: java.lang.IllegalStateException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}}, > "rolled-back" => true > } > {code} > NPE in server log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service org.wildfly.security.authentication-configuration.cfg2: org.jboss.msc.service.StartException in service org.wildfly.security.authentication-configuration.cfg2: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException: java.lang.NullPointerException > at org.wildfly.extension.elytron.AuthenticationClientDefinitions$1.lambda$getValueSupplier$17(AuthenticationClientDefinitions.java:364) > at java.util.function.Function.lambda$andThen$5(Function.java:88) > at org.wildfly.extension.elytron.AuthenticationClientDefinitions$1.lambda$getValueSupplier$18(AuthenticationClientDefinitions.java:370) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > ... 3 more > Caused by: java.lang.NullPointerException > at org.wildfly.extension.elytron.AuthenticationClientDefinitions$1.lambda$getValueSupplier$17(AuthenticationClientDefinitions.java:359) > ... 8 more > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2943) Runtime attribute loaded-providers of elytron provider-loader should not be required

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2943?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-11467 to WFCORE-2943: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2943 (was: JBEAP-11467) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) (was: User Experience) Affects Version/s: 3.0.0.Beta26 (was: 7.1.0.DR15) Fix Version/s: (was: 7.1.0.GA) > Runtime attribute loaded-providers of elytron provider-loader should not be required > ------------------------------------------------------------------------------------ > > Key: WFCORE-2943 > URL: https://issues.jboss.org/browse/WFCORE-2943 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta26 > Reporter: Chao Wang > Assignee: Chao Wang > > Runtime attribute being required (and thus nillable false) is confusing for users. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1110) Update AuthenticationContextTest

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1110?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1110: ------------------------------ Fix Version/s: 1.1.0.Beta41 > Update AuthenticationContextTest > -------------------------------- > > Key: ELY-1110 > URL: https://issues.jboss.org/browse/ELY-1110 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.1.0.Beta38 > Reporter: Ondrej Lukas > Assignee: Ondrej Lukas > Fix For: 1.1.0.Beta41 > > > Update AuthenticationContextTest due to ELY-987 has been resolved. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1905) windows service (service.bat) failed to install if the value of /serviceuser has a white space inside

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1905?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1905: ------------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1220683|https://bugzilla.redhat.com/show_bug.cgi?id=1220683] from ASSIGNED to CLOSED > windows service (service.bat) failed to install if the value of /serviceuser has a white space inside > ----------------------------------------------------------------------------------------------------- > > Key: WFCORE-1905 > URL: https://issues.jboss.org/browse/WFCORE-1905 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Reporter: Brad Maxwell > Assignee: Tomaz Cerar > Priority: Minor > Fix For: 3.0.0.Alpha11 > > > When using "service.bat install /serviceuser ..." command to install window service, if the account name behind /serviceuser has a whit space inside like ".\JBoss User", it will failed to install windows service. > Run command: service.bat install /serviceuser ".\JBoss User" /servicepass "change it" /startup /debug > When starting it, an error window poped up: > {code} > Windows could not start the JBossEAP6 on Local Computer. > For more information, review the System Event Log. > If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code1. > {code} > Additional info: > Possible fix is editing "service.bat" and add double quotation marks on %SERVICE_USER% > From > {code} > set RUNAS=--ServiceUser=%SERVICE_USER% --ServicePassword=%SERVICE_PASS% > {code} > to > {code} > set RUNAS=--ServiceUser="%SERVICE_USER%" --ServicePassword="%SERVICE_PASS%" > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8917) EJB run-as identity gets lost if an unsecured ejb in the call stack

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8917?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-8917: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1460347 Bugzilla Update: Perform > EJB run-as identity gets lost if an unsecured ejb in the call stack > -------------------------------------------------------------------- > > Key: WFLY-8917 > URL: https://issues.jboss.org/browse/WFLY-8917 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Attachments: SimpleEAR_EJB3.ear > > > Having an unsecured EJB in the call stack will cause the RunAs identity to get lost. > An example might look like this: > unsecured web app (RunAs: JBossAdmin) -> unsecured HelloBean EJB -> secured GoodBye EJB (RolesAllowed: JBossAdmin) > This will fail as the unsecured ejb causes the RunAs identity to get dropped/lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8917) EJB run-as identity gets lost if an unsecured ejb in the call stack

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/WFLY-8917?page=com.atlassian.jira.plugin.... ] Derek Horton updated WFLY-8917: ------------------------------- Description: Having an unsecured EJB in the call stack will cause the RunAs identity to get lost. An example might look like this: unsecured web app (RunAs: JBossAdmin) -> unsecured HelloBean EJB -> secured GoodBye EJB (RolesAllowed: JBossAdmin) This will fail as the unsecured ejb causes the RunAs identity to get dropped/lost. was: Having an unsecured EJB in the call stack will cause the RunAs identity to get lost. An example might look like this: unsecured web app (RunAs: JBossAdmin) -> unsecured EJB -> secured EJB (RolesAllowed: JBossAdmin) This will fail as the unsecured ejb causes the RunAs identity to get dropped/lost. > EJB run-as identity gets lost if an unsecured ejb in the call stack > -------------------------------------------------------------------- > > Key: WFLY-8917 > URL: https://issues.jboss.org/browse/WFLY-8917 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Attachments: SimpleEAR_EJB3.ear > > > Having an unsecured EJB in the call stack will cause the RunAs identity to get lost. > An example might look like this: > unsecured web app (RunAs: JBossAdmin) -> unsecured HelloBean EJB -> secured GoodBye EJB (RolesAllowed: JBossAdmin) > This will fail as the unsecured ejb causes the RunAs identity to get dropped/lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8917) EJB run-as identity gets lost if an unsecured ejb in the call stack

by Derek Horton (JIRA)

[ https://issues.jboss.org/browse/WFLY-8917?page=com.atlassian.jira.plugin.... ] Derek Horton updated WFLY-8917: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/10179 > EJB run-as identity gets lost if an unsecured ejb in the call stack > -------------------------------------------------------------------- > > Key: WFLY-8917 > URL: https://issues.jboss.org/browse/WFLY-8917 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Derek Horton > Assignee: Darran Lofthouse > Attachments: SimpleEAR_EJB3.ear > > > Having an unsecured EJB in the call stack will cause the RunAs identity to get lost. > An example might look like this: > unsecured web app (RunAs: JBossAdmin) -> unsecured EJB -> secured EJB (RolesAllowed: JBossAdmin) > This will fail as the unsecured ejb causes the RunAs identity to get dropped/lost. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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