October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second

by Masafumi Miura (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1355?page=com.atlassian.jira.plugin... ] Masafumi Miura updated JBJCA-1355: ---------------------------------- Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/637, https://github.com/ironjacamar/ironjacamar/pull/638 > set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second > ---------------------------------------------------------------------------------------------------- > > Key: JBJCA-1355 > URL: https://issues.jboss.org/browse/JBJCA-1355 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Reporter: Masafumi Miura > > {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}. > --- > {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok. > However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue. > Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch): > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 2022 /** > 2023 * Check configured query timeout > 2024 * @param ws The statement > 2025 * @param explicitTimeout An explicit timeout value set > 2026 * @exception SQLException Thrown if an error occurs > 2027 */ > 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException > 2029 { > 2030 if (mc == null || dataSource == null) > 2031 return; > 2032 > 2033 int timeout = 0; > 2034 > 2035 // Use the transaction timeout > 2036 if (mc.isTransactionQueryTimeout()) > 2037 { > 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout(); > 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout) > 2040 timeout = explicitTimeout; > 2041 } > 2042 > 2043 // Look for a configured value > 2044 if (timeout <= 0 && explicitTimeout <= 0) > 2045 timeout = mc.getQueryTimeout(); > 2046 > 2047 if (timeout > 0) > 2048 ws.setQueryTimeout(timeout); > 2049 } > {code} > - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... > {code} > 190 /** > 191 * Get the time left before a transaction timeout > 192 * @return The amount in seconds; <code>-1</code> if no timeout > 193 * @exception SQLException Thrown if an error occurs > 194 */ > 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException > 196 { > 197 try > 198 { > 199 if (cm instanceof TransactionTimeoutConfiguration) > 200 { > 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true); > 202 // No timeout > 203 if (timeout == -1) > 204 return -1; > 205 // Round up to the nearest second > 206 long result = timeout / 1000; > 207 if ((result % 1000) != 0) > 208 ++result; > 209 return (int) result; > 210 } > 211 else > 212 return -1; > 213 } > 214 catch (RollbackException e) > 215 { > 216 throw new SQLException(e); > 217 } > 218 } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1355) set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second

by Masafumi Miura (JIRA)

Masafumi Miura created JBJCA-1355: ------------------------------------- Summary: set-tx-query-timeout does not work when the remaining transaction timeout is shorter than one second Key: JBJCA-1355 URL: https://issues.jboss.org/browse/JBJCA-1355 Project: IronJacamar Issue Type: Bug Components: JDBC Reporter: Masafumi Miura {{set-tx-query-timeout}} setting does not work when the remaining transaction timeout is shorter than one second (between 0-999 millis) due to incorrect round-up in IronJacamar {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}}. --- {{WrappedConnection#checkConfiguredQueryTimeout()}} checks the returned value from {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} and set the value to query timeout if it's larger than 0. If it's not larger than 0, the configured query timeout ({{query-timeout}} in datasource setting) is used. This behavior itself is ok. However, {{WrapperDataSource#getTimeLeftBeforeTransactionTimeout()}} incorrectly rounds up the returned value from transaction manager's {{TransactionTimeoutConfiguration#getTimeLeftBeforeTransactionTimeout()}}. And it results in returning 0 when the remaining transaction timeout is between 0-999 millis. This causes the issue. Here's the related code from 1.3.7.Final (It's same in the latest 1.3 branch and 1.4 branch): - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... {code} 2022 /** 2023 * Check configured query timeout 2024 * @param ws The statement 2025 * @param explicitTimeout An explicit timeout value set 2026 * @exception SQLException Thrown if an error occurs 2027 */ 2028 void checkConfiguredQueryTimeout(WrappedStatement ws, int explicitTimeout) throws SQLException 2029 { 2030 if (mc == null || dataSource == null) 2031 return; 2032 2033 int timeout = 0; 2034 2035 // Use the transaction timeout 2036 if (mc.isTransactionQueryTimeout()) 2037 { 2038 timeout = dataSource.getTimeLeftBeforeTransactionTimeout(); 2039 if (timeout > 0 && explicitTimeout > 0 && timeout > explicitTimeout) 2040 timeout = explicitTimeout; 2041 } 2042 2043 // Look for a configured value 2044 if (timeout <= 0 && explicitTimeout <= 0) 2045 timeout = mc.getQueryTimeout(); 2046 2047 if (timeout > 0) 2048 ws.setQueryTimeout(timeout); 2049 } {code} - https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.3.7.Final/a... {code} 190 /** 191 * Get the time left before a transaction timeout 192 * @return The amount in seconds; <code>-1</code> if no timeout 193 * @exception SQLException Thrown if an error occurs 194 */ 195 protected int getTimeLeftBeforeTransactionTimeout() throws SQLException 196 { 197 try 198 { 199 if (cm instanceof TransactionTimeoutConfiguration) 200 { 201 long timeout = ((TransactionTimeoutConfiguration) cm).getTimeLeftBeforeTransactionTimeout(true); 202 // No timeout 203 if (timeout == -1) 204 return -1; 205 // Round up to the nearest second 206 long result = timeout / 1000; 207 if ((result % 1000) != 0) 208 ++result; 209 return (int) result; 210 } 211 else 212 return -1; 213 } 214 catch (RollbackException e) 215 { 216 throw new SQLException(e); 217 } 218 } {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9406: ------------------------------ Priority: Minor (was: Critical) > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-9406: --------------------------------- Assignee: Alessio Soldano (was: Martin Kouba) Alessio, assigning to you as asm is only used by cxf / webservices stack. If you are ok with it, I can send PR. > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Critical > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9406: ------------------------------ Component/s: Build System Web Services (was: CDI / Weld) (was: Class Loading) (was: REST) > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Martin Kouba > Priority: Critical > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-9406: ------------------------------ Fix Version/s: 12.0.0.Alpha1 (was: 11.0.0.Final) > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld, Class Loading, REST > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Martin Kouba > Priority: Critical > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1375) Digest auth uses single use nonces with no Authentication-Info header

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/ELY-1375?page=com.atlassian.jira.plugin.s... ] Stuart Douglas moved JBEAP-13297 to ELY-1375: --------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1375 (was: JBEAP-13297) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Security) Target Release: (was: 7.backlog.GA) > Digest auth uses single use nonces with no Authentication-Info header > --------------------------------------------------------------------- > > Key: ELY-1375 > URL: https://issues.jboss.org/browse/ELY-1375 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Blocker > > The results in every single request being retried -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] jaikiran pai commented on WFLY-9406: ------------------------------------ I don't fully understand how the version of ASM that WildFly uses internally should impact Jacoco. Can you add more details on what issues you are running into, including any exception stacktraces? The whole point of a modular classloading is to avoid issues like these and as far as I know, WildFly doesn't attach/expose the ASM module (automatically) into the deployments. > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: CDI / Weld, Class Loading, REST > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Martin Kouba > Priority: Critical > Fix For: 11.0.0.Final > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

6 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017