October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-650) Improvements to Elytron Web and Undertow Testsuite

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-650?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-650: --------------------------------- Fix Version/s: 1.1.0.Beta12 (was: 1.1.0.Beta11) > Improvements to Elytron Web and Undertow Testsuite > -------------------------------------------------- > > Key: ELY-650 > URL: https://issues.jboss.org/browse/ELY-650 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Affects Versions: 1.1.0.Beta10 > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 1.1.0.Beta12 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-625) Include the client schema in the jar

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-625?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-625: --------------------------------- Fix Version/s: 1.1.0.Beta12 (was: 1.1.0.Beta11) > Include the client schema in the jar > ------------------------------------ > > Key: ELY-625 > URL: https://issues.jboss.org/browse/ELY-625 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta12 > > > We need to get the schema into the jar so when assembled in a WildFly feature pack it can be extracted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-617) Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-617?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-617: --------------------------------- Fix Version/s: 1.1.0.Beta12 (was: 1.1.0.Beta11) > Review 'null' handling for MechanismConfiguration and MechanismRealmConfiguration > --------------------------------------------------------------------------------- > > Key: ELY-617 > URL: https://issues.jboss.org/browse/ELY-617 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta12 > > > Javadoc states various NameRewriter instances will not be null, implementation suggests otherwise. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-639) SecurityIdentity and PeerIdentity should have more runAs* variants

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-639?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-639: --------------------------------- Fix Version/s: 1.1.0.Beta12 (was: 1.1.0.Beta11) > SecurityIdentity and PeerIdentity should have more runAs* variants > ------------------------------------------------------------------ > > Key: ELY-639 > URL: https://issues.jboss.org/browse/ELY-639 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: David Lloyd > Fix For: 1.1.0.Beta12 > > > The XxxIdentity classes have fewer runAs modes than (for example) Contextual objects do. Unifying these types would be ideal, but I'd settle for adding the missing types, including the {{Exception*}} functional types from WildFly Common. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-643) On the SSLContextBuilder support setUseCipherSuitesOrder

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-643?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-643: --------------------------------- Fix Version/s: 1.1.0.Beta12 (was: 1.1.0.Beta11) > On the SSLContextBuilder support setUseCipherSuitesOrder > -------------------------------------------------------- > > Key: ELY-643 > URL: https://issues.jboss.org/browse/ELY-643 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.1.0.Beta12 > > > Currently we hard code this value to 'true' which should remain the default as the OpenSSL style cipher suite selection includes preferred mechanism ordering - however it should be possible to override this and set it to false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-649) Make the exists and create methods on HttpScope default

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-649?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-649: --------------------------------- Fix Version/s: 1.1.0.Beta12 (was: 1.1.0.Beta11) > Make the exists and create methods on HttpScope default > ------------------------------------------------------- > > Key: ELY-649 > URL: https://issues.jboss.org/browse/ELY-649 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 1.1.0.Beta12 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-613) Some nested classes should be considered to be static nested in Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-613?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-613: --------------------------------- Fix Version/s: 1.1.0.Beta12 (was: 1.1.0.Beta11) > Some nested classes should be considered to be static nested in Elytron > ----------------------------------------------------------------------- > > Key: ELY-613 > URL: https://issues.jboss.org/browse/ELY-613 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: static_analysis > Fix For: 1.1.0.Beta12 > > > There are some inner classes in Elytron which should be considered to be static nested to avoid dependency on their outer class. Following nested classes should be considered: > * LoadedIdentity and Identity from org.wildfly.security.auth.realm.FileSystemSecurityRealm > * DecoderState from org.wildfly.security.asn1.DERDecoder > * AccountEntry from org.wildfly.security.auth.realm.LegacyPropertiesSecurityRealm > * JaasAuthorizationIdentity and DefaultCallbackHandler from org.wildfly.security.auth.realm.JaasSecurityRealm > * LoadKey from org.wildfly.security.keystore.AtomicLoadKeyStore -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6885) Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper

by Marcel Kolsteren (JIRA)

[ https://issues.jboss.org/browse/WFLY-6885?page=com.atlassian.jira.plugin.... ] Marcel Kolsteren commented on WFLY-6885: ---------------------------------------- Apparently the auto-assign has left the issue unassigned. Can someone please assign it? I think exception swallowing is a major issue. > Exception swallowed by CmtTxInterceptor if transaction has been cancelled by reaper > ----------------------------------------------------------------------------------- > > Key: WFLY-6885 > URL: https://issues.jboss.org/browse/WFLY-6885 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 10.0.0.Final > Reporter: Marcel Kolsteren > Attachments: tx-timeout.zip > > > The CMTTxInterceptor is responsible for starting a transaction if a public method is called on a session bean, and for ending it (commit or rollback) after the method has returned. If a runtime exception occurs during the execution of the public method, WildFly normally throws an EJBException with the original exception as cause. However, if the transaction has timed out, it swallows the original exception, and throws a EJBTransactionRolledBackException without a root cause. That obscures what actually happened during the execution of the public method. > I attached a zip with an small Arquillian project that shows (1) what happens in case of an exception in combination with an active transaction (the succeeding test) and (2) what happens if the exception occurs when the transaction has timed out (the failing test). > I think that the exception swallow is explainable as follows, referring to the 10.0.0.Final version of CMTTxInterceptor, that can be found here > [https://github.com/wildfly/wildfly/blob/10.0.0.Final/ejb3/src/main/java/o...] > This happens (I verified by stepping through the code with the debugger): > * The catch block of invokeInOurTx is entered. > * The method handleExceptionInOurTx tries to set the "rollback only" status on the transaction. The result is that the transaction, which has already been rolled back, stays in the rolled back state. A new EJBException is thrown, wrapping the original runtime exception. > * The finally block of invokeInOurTx is entered. > * The endTransaction method sees that the transaction is in the rolled back state, and concludes that the "reaper canceled (rolled back) tx case" is applicable. It throws a new exception (which replaces the EJBException that just has been thrown), but that new exception doesn't have a cause. > The desired behavior would be that the interceptor only wraps the original exception in an EJBException in this case. I think that the invokeInOurTx method should only call the endTransaction method, if the transaction is not in the rolled back state. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2110) Transport: revisit buffers and threading

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2110?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2110: -------------------------------- Measure performance on edg-perf. The current thinking is that I'll revisit this in 5.0 when supporting direct buffers and off-heap. > Transport: revisit buffers and threading > ---------------------------------------- > > Key: JGRP-2110 > URL: https://issues.jboss.org/browse/JGRP-2110 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > (Concerns only the receiver side) > h4. Parsing > Currently, parsing is done on the thread which received the message (or message batch) and then the message is passed on to the thread pool. One could argue that the parsing should be done on the thread from the thread pool, and the receiver thread should only fill the buffer and pass it to the thread pool immediately, without doing any parsing, as this might slow it down. > This actually used to be the model which JGroups used, but I abandoned it because (1) performance (IspnPerfTest and UPerf) was the same and (2) we could get rid of a buffer copy (more on this below). > h4. Buffers > * UDP has a fixed buffer of 65K. A datagram packet is read into this buffer and then parsed and passed to the thread pool, allowing the buffer to be reused for the next message. > * TCP: each connection has a buffer which grows according to the length sent in the header of a message. This buffer doesn't need to be copied when passed up the stack, until receive() returns > * TCP_NIO2: each connection also has a buffer which is reused after receive(), but if the read is not complete, is copied. > h4. Approaches > # The receiver thread parses the buffer into a message and passes the message to the thread pool for processing. This requires memory allocation (the new message and its payload buffer). This is the current approach. Parsing the buffer into a message might slow things down as message creation requires memory allocation. > # The receiver thread passes the buffer on to the thread pool where it is parsed. The advantage is that the receiver thread is immediately ready to receive new messages. The disadvantage is that this is 1x memory allocation for the message (as above), although done on a seperate thread, plus 1x memory allocation for copying of the buffer to reuse the original buffer (where necessary, depending on the transport). This was the old way of handling incoming messages. > # UDP: it is possible for the socket receive() method to be called by multiple threads. We could therefore create multiple receiver threads in UDP, to speed things up. > # To prevent memory allocation of the approaches above, we could create a buffer pool. The receiver thread grabs a buffer from the pool (the pool creates a new one when empty?) and fills it with the socket's receive() method, then passes the buffer to the thread pool for processing. If the message's payload buffer points to the original buffer (from the buffer pool), the thread from the thread pool returns the buffer to the buffer pool as soon as the {{receive()}} callback returns, otherwise it returns it as soon as the message has been parsed. > h4. Goals > Prototype approaches 2, 3 and 4 and benchmark them against each other, using UPerf and IspnPerfTest. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2111) Sticky site masters

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2111?page=com.atlassian.jira.plugin.... ] Bela Ban deleted JGRP-2111: --------------------------- > Sticky site masters > ------------------- > > Key: JGRP-2111 > URL: https://issues.jboss.org/browse/JGRP-2111 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > > If members in one site send messages to site masters of other sites, if we have multiple site masters, then reordering can occur. > Example: > * Member C in site LON sends messages C1 and C2 to site NYC > * C1 picks SM1 and C2 picks SM2 > * Although site masters process messages in delivery order, because C1 and C2 travel through different site masters, C2 could pass C1, leading to ordering issues -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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 October 2016