November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1987) TransferQueueBundler: use ring buffer rather than linked queue

by Bela Ban (JIRA)

Bela Ban created JGRP-1987: ------------------------------ Summary: TransferQueueBundler: use ring buffer rather than linked queue Key: JGRP-1987 URL: https://issues.jboss.org/browse/JGRP-1987 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.6.7 {{LinkedBlockingQueue}} creates new entries for new elements, creating a steady memory churn. Use a fixed size array or ring buffer of {{capacity}} elements instead. Possibly a new bundler implementation, to be able to contrast it to the existing one for performance. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-377) Add a SecurityFactory implementation to return a GSSCredential

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-377?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-377: --------------------------------- Is this one of those things that varies by JDK vendor? > Add a SecurityFactory implementation to return a GSSCredential > -------------------------------------------------------------- > > Key: ELY-377 > URL: https://issues.jboss.org/browse/ELY-377 > Project: WildFly Elytron > Issue Type: Task > Components: Utils > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta3 > > > This task is for a simple implementation that uses a JAAS call and the GSSAPI APIs to authenticate and obtain the GSSCredential. > For completeness this utility should probably cover both the client side and server side use cases. > Delegation however may call for a slightly different implement for the client side when running in a server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1986) TransferQueueBundler: sending messages one-by-one when threshold has been exceeded

by Bela Ban (JIRA)

Bela Ban created JGRP-1986: ------------------------------ Summary: TransferQueueBundler: sending messages one-by-one when threshold has been exceeded Key: JGRP-1986 URL: https://issues.jboss.org/browse/JGRP-1986 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban In {{TP.TransferQueueBundler}}, when the queue's threshold (90% of the queue's capacity) is exceeded, messages are dequeued and sent one-by-one. See {{queue.take()}} and {{queue.poll()}} below. This is inefficient and slows down sending of messages until the queue size falls below the threshold again. Solution: remove {{threshold}} and the associated checks. {noformat} public void run() { while(Thread.currentThread() == bundler_thread) { Message msg=null; try { if(count == 0) { msg=queue.take(); if(msg == null) continue; long size=msg.size(); if(count + size >= max_bundle_size || queue.size() >= threshold) sendBundledMessages(); addMessage(msg, size); } while(null != (msg=queue.poll())) { long size=msg.size(); if(count + size >= max_bundle_size || queue.size() >= threshold) sendBundledMessages(); addMessage(msg, size); } if(count > 0) sendBundledMessages(); } catch(Throwable t) { } } } {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1160?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-1160: ------------------------------------- I would suggest changing from {{Class<T>}} to some other type-checking mechanism e.g. a {{Function<Object, T>}} casting function. The {{Class<T>}} API can be emulated by using a lambda {{obj -> clazz.cast(obj)}}. > Definition of capabilities where the service return type is generic. > -------------------------------------------------------------------- > > Key: WFCORE-1160 > URL: https://issues.jboss.org/browse/WFCORE-1160 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Labels: affects_elytron > Fix For: 3.0.0.Alpha1 > > > Within Elytron we have the following interface: - > {code} > public interface SecurityFactory<T> {} > {code} > It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. > As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1160) Definition of capabilities where the service return type is generic.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-1160: ---------------------------------------- Summary: Definition of capabilities where the service return type is generic. Key: WFCORE-1160 URL: https://issues.jboss.org/browse/WFCORE-1160 Project: WildFly Core Issue Type: Enhancement Components: Domain Management Reporter: Darran Lofthouse Assignee: Brian Stansberry Fix For: 3.0.0.Alpha1 Within Elytron we have the following interface: - {code} public interface SecurityFactory<T> {} {code} It is desirable to define capabilities where the generic type is specified so that as we wire together the various services we can be sure the correct SecurityFactory services are injected in the correct locations. As it stands our only option is going to be a runtime check so incorrectly wired SecurityFactory references will only occur late. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-377) Add a SecurityFactory implementation to return a GSSCredential

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-377: ------------------------------------ Summary: Add a SecurityFactory implementation to return a GSSCredential Key: ELY-377 URL: https://issues.jboss.org/browse/ELY-377 Project: WildFly Elytron Issue Type: Task Components: Utils Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta3 This task is for a simple implementation that uses a JAAS call and the GSSAPI APIs to authenticate and obtain the GSSCredential. For completeness this utility should probably cover both the client side and server side use cases. Delegation however may call for a slightly different implement for the client side when running in a server. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-376) Password policies

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-376?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-376: --------------------------------- I assume that I wasn't intentionally the assignee here, but either way, I'll give some design opinion. :-) This, ELY-369, and other things that have come up in discussion are all pointing to a policy layer above the realm where such things could be implemented. SecurityDomain is the logical target given that the original intention of it was to aggregate all policy (something we've adhered to reasonably well thus far). However there are limits to what we're equipped to support there at present; for example we have no structural mechanism to accommodate password history. That is something that would need special support in the realm. But checking things like password complexity measurement, valid/invalid characters (SASLPrep maybe getting involved here), expiration, and length are all possible. That said, if we do take this on, as a public service we should forbid or warn about foolish policies, e.g. policies which restrict password length to a short length like 8 or 10 yet require a high password complexity. > Password policies > ----------------- > > Key: ELY-376 > URL: https://issues.jboss.org/browse/ELY-376 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI, Passwords, Realms > Reporter: Darran Lofthouse > Assignee: David Lloyd > Fix For: 1.1.0.Beta3 > > > Probably needs a design discussion first but we need to review where password policies fit in to the overall solution. > We may say that policy handling is really the responsibility of the actual realm implementation, after all items such as history are going to be very realm specific. > However there may also be a case in the generic sense that where a modifiable realm is in use a policy is desired to cover the complexity of any passwords set on that realm. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-376) Password policies

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-376: ------------------------------------ Summary: Password policies Key: ELY-376 URL: https://issues.jboss.org/browse/ELY-376 Project: WildFly Elytron Issue Type: Feature Request Components: API / SPI, Passwords, Realms Reporter: Darran Lofthouse Assignee: David Lloyd Fix For: 1.1.0.Beta3 Probably needs a design discussion first but we need to review where password policies fit in to the overall solution. We may say that policy handling is really the responsibility of the actual realm implementation, after all items such as history are going to be very realm specific. However there may also be a case in the generic sense that where a modifiable realm is in use a policy is desired to cover the complexity of any passwords set on that realm. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-372) Add runAs* variants that are lambda-friendly

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-372?page=com.atlassian.jira.plugin.sy... ] David Lloyd resolved ELY-372. ----------------------------- Resolution: Done > Add runAs* variants that are lambda-friendly > -------------------------------------------- > > Key: ELY-372 > URL: https://issues.jboss.org/browse/ELY-372 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Minor > Fix For: 1.1.0.Beta2 > > > The runAs* methods are overloaded and thus are hostile to lambdas. Add variations that do not have ambiguous overloads and which accept (Bi)Function, (Bi)Consumer, and Supplier arguments. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-892) Cli output of some tests contains only "0: " (instead of correct result)

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-892?page=com.atlassian.jira.plugin... ] Martin Choma reopened WFCORE-892: --------------------------------- As stated in https://issues.jboss.org/browse/JBEAP-764, timeout issues still can be seen. > Cli output of some tests contains only "0: " (instead of correct result) > ------------------------------------------------------------------------ > > Key: WFCORE-892 > URL: https://issues.jboss.org/browse/WFCORE-892 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.0.Beta2 > Reporter: Marek Kopecký > Assignee: Filip Bogyai > Fix For: 2.0.0.Beta5 > > > *Description of problem:* > Cli output of some tests in wildfly core contains only "0: " (instead of correct result) > *How reproducible:* > 66% on RHEL && IBM JDK 8 > *Affected tests found so far:* > * org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase#testWrongVaultPassword > ** {noformat}java.lang.AssertionError: Password should be wrong > Expected: a string containing "Keystore was tampered with, or password was incorrect" > but: was "0: " > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.junit.Assert.assertThat(Assert.java:865) > at org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase.testWrongVaultPassword(VaultPasswordsInCLITestCase.java:135){noformat} > * org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase#testRightVaultPassword > ** {noformat}java.lang.AssertionError: Password should be right and authentication successful > Expected: a string containing "\"outcome\" => \"success\"" > but: was "0: " > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.junit.Assert.assertThat(Assert.java:865) > at org.jboss.as.test.manualmode.vault.VaultPasswordsInCLITestCase.testRightVaultPassword(VaultPasswordsInCLITestCase.java:148){noformat} > * org.wildfly.core.test.standalone.mgmt.HTTPSConnectionWithCLITestCase#testTrustedCLICertificate > * org.jboss.as.test.manualmode.management.cli.CustomVaultInCLITestCase#testWrongVaultPassword > *Steps to Reproduce:* > # mvn install -Dts.manualmode -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -DfailIfNoTests=false -Dtest=VaultPasswordsInCLITestCase -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 2015