October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3801) Wrong Transaction behaviour for EJBs if JTS is enabled

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-3801?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-3801: --------------------------------- Assignee: Stuart Douglas (was: David Lloyd) > Wrong Transaction behaviour for EJBs if JTS is enabled > ------------------------------------------------------ > > Key: WFLY-3801 > URL: https://issues.jboss.org/browse/WFLY-3801 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 8.1.0.Final > Environment: standalone-full profile with JTS enabled > Reporter: Wolf-Dieter Fink > Assignee: Stuart Douglas > Attachments: 456a624-withDestroy.log, 8d49872-error.log, enableJTS.cli, reproducer.zip, server.log > > > If JTS is enabled the invocation of EJB's might show a arjuna warning for each method invocation: > WARN [com.arjuna.ats.jts] (RequestProcessor-5) ARJUNA022261: ServerTopLevelAction detected that the transaction was inactive > This is only the case if other resources are involved, i.e. a DB via JPA. > If a simple bean is used (like ejb-remote quickstart) this warning is not shown. > It looks like the transaction is local commited but in case of a SFSB @Remove method the result is a " WFLYEE0006: Failed to destroy component instance Instance of SFTestBean" and the lifecycle method @PreDestroy is not invoked. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-302) Add SHA-512-256 to list of algorithms for digest passwords and SASL digest

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-302?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-302: -------------------------------- MessageDigest wrapper allowing this is already implemented in elytron: https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... > Add SHA-512-256 to list of algorithms for digest passwords and SASL digest > -------------------------------------------------------------------------- > > Key: ELY-302 > URL: https://issues.jboss.org/browse/ELY-302 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Passwords, SASL > Reporter: David Lloyd > > [RFC 7616|http://www.rfc-editor.org/rfc/rfc7616.txt] was released, indicating that SHA-512-256 is a supported algorithm for digest HTTP mechanisms. We need support for that algorithm as a password. We also then should add a corresponding SASL variant to the DIGEST suite. > There is no MessageDigest for SHA-512-256. This can be accomplished by truncating the output of SHA-512 to 256 bits (32 bytes). A wrapper MessageDigest could be created, or the ability to arbitrarily truncate the digest could be added to the DIGEST mechanism. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-302) Add SHA-512-256 to list of algorithms for digest passwords and SASL digest

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-302?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-302: ------------------------------ Assignee: Jan Kalina > Add SHA-512-256 to list of algorithms for digest passwords and SASL digest > -------------------------------------------------------------------------- > > Key: ELY-302 > URL: https://issues.jboss.org/browse/ELY-302 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Passwords, SASL > Reporter: David Lloyd > Assignee: Jan Kalina > > [RFC 7616|http://www.rfc-editor.org/rfc/rfc7616.txt] was released, indicating that SHA-512-256 is a supported algorithm for digest HTTP mechanisms. We need support for that algorithm as a password. We also then should add a corresponding SASL variant to the DIGEST suite. > There is no MessageDigest for SHA-512-256. This can be accomplished by truncating the output of SHA-512 to 256 bits (32 bytes). A wrapper MessageDigest could be created, or the ability to arbitrarily truncate the digest could be added to the DIGEST mechanism. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3393: ------------------------------------------ The relevant code is all in the protocol module though, which makes this more feasible. > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3393: ------------------------------------------ [~jdenise] Thanks. That looks tricky, as that logic is called from far away from any overall timeout setting. > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-3393: ----------------------------------------- Description: This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. was: The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-3393: ---------------------------------------------- [~brian.stansberry], I updated the description. > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > This applies to the protocol module. The timeout is :https://github.com/wildfly/wildfly-core/blob/master/protocol/src/main/java/org/jboss/as/protocol/mgmt/FutureManagementChannel.java#L154 > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9508) Drop mod_cluster transformers for model versions prior to EAP 6.4

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9508?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-9508: --------------------------------- Fix Version/s: 12.0.0.Alpha1 > Drop mod_cluster transformers for model versions prior to EAP 6.4 > ----------------------------------------------------------------- > > Key: WFLY-9508 > URL: https://issues.jboss.org/browse/WFLY-9508 > Project: WildFly > Issue Type: Task > Components: mod_cluster > Affects Versions: 11.0.0.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 12.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3393) Connection Timeout should take into account time spent in opening the channel

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3393?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3393: ------------------------------------------ Where is this 10 set? > Connection Timeout should take into account time spent in opening the channel > ----------------------------------------------------------------------------- > > Key: WFCORE-3393 > URL: https://issues.jboss.org/browse/WFCORE-3393 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Jean-Francois Denise > Assignee: Brian Stansberry > > The connection timeout applies to protocol establishment only, an hardcoded timeout of 10 seconds is dedicated to the channel.open. > This can create an unexpected behaviour in case we have a fast connection establishment and for some reason (as seen in JBEAP-11859) a slow channel open. Whatever the timeout in use, 10 seconds is what the user will get. > In order to offer a coherent timeout, the time that remains after the connection establishment should be dedicated to the channel open. If we want to keep existing behaviour, if the remaining is less than 10 seconds, then 10 seconds should be used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9508) Drop mod_cluster transformers for model versions prior to EAP 6.4

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-9508: ------------------------------------ Summary: Drop mod_cluster transformers for model versions prior to EAP 6.4 Key: WFLY-9508 URL: https://issues.jboss.org/browse/WFLY-9508 Project: WildFly Issue Type: Task Components: mod_cluster Reporter: Radoslav Husar Assignee: Radoslav Husar -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 12 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017