October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed

by lorenzo benvenuti (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ] lorenzo benvenuti commented on JBJCA-1321: ------------------------------------------ Thank you Stefano (next time I'll post the question in the forum). lorenzo > Statement.cancel() is not invoked until the statement is completed > ------------------------------------------------------------------ > > Key: JBJCA-1321 > URL: https://issues.jboss.org/browse/JBJCA-1321 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: lorenzo benvenuti > Assignee: Lin Gao > Priority: Critical > Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final > > > Hi, > in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}: > {code:java} > public void cancel() throws SQLException > { > if (doLocking) > lock(); > try > { > /* ... */ > {code} > It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. > Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion. > Thank you, > lorenzo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1854) Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-1854: ------------------------------------------- Fixed by WFCORE-1851 > Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-1854 > URL: https://issues.jboss.org/browse/WFCORE-1854 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha9 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result: > {code}{ > "outcome" => "success", > "result" => [ > { > "path" => "META-INF/", > "directory" => true > }, > { > "path" => "META-INF/MANIFEST.MF", > "directory" => false, > "file-size" => 130L > }, > { > "path" => "jboss-kitchensink-ear-web.war", > "directory" => false, > "file-size" => 63190L > }, > { > "path" => "jboss-kitchensink-ear-ejb.jar", > "directory" => false, > "file-size" => 12256L > }, > { > "path" => "META-INF/application.xml", > "directory" => false, > "file-size" => 802L > }, > { > "path" => "META-INF/kitchensink-ear-quickstart-ds.xml", > "directory" => false, > "file-size" => 1955L > }, > { > "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml", > "directory" => false, > "file-size" => 5582L > }, > { > "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties", > "directory" => false, > "file-size" => 143L > } > ] > } > {code} > WFCORE-1851 does not fix this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1854) Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1854?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet closed WFCORE-1854. ------------------------------------- Resolution: Cannot Reproduce Bug > Wrong result on :browse-content(depth>0) on archived deployments deployed by deployment scanner > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-1854 > URL: https://issues.jboss.org/browse/WFCORE-1854 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha9 > Reporter: Michal Jurc > Assignee: ehsavoie Hugonnet > > With archived deployment deployed by deployment scanner, the {{/deployment=jboss-kitchensink-ear.ear:browse-content(depth=1)}} command returns the following result: > {code}{ > "outcome" => "success", > "result" => [ > { > "path" => "META-INF/", > "directory" => true > }, > { > "path" => "META-INF/MANIFEST.MF", > "directory" => false, > "file-size" => 130L > }, > { > "path" => "jboss-kitchensink-ear-web.war", > "directory" => false, > "file-size" => 63190L > }, > { > "path" => "jboss-kitchensink-ear-ejb.jar", > "directory" => false, > "file-size" => 12256L > }, > { > "path" => "META-INF/application.xml", > "directory" => false, > "file-size" => 802L > }, > { > "path" => "META-INF/kitchensink-ear-quickstart-ds.xml", > "directory" => false, > "file-size" => 1955L > }, > { > "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.xml", > "directory" => false, > "file-size" => 5582L > }, > { > "path" => "META-INF/maven/org.jboss.quickstarts.eap/jboss-kitchensink-ear-ear/pom.properties", > "directory" => false, > "file-size" => 143L > } > ] > } > {code} > WFCORE-1851 does not fix this. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ] Stefano Maestri commented on JBJCA-1321: ---------------------------------------- It would be better to ask this questions through our forum than jira. Anyway the steps you described are correct. An alternative would be building latest 1.2 branch which already include this patch. regards S. > Statement.cancel() is not invoked until the statement is completed > ------------------------------------------------------------------ > > Key: JBJCA-1321 > URL: https://issues.jboss.org/browse/JBJCA-1321 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: lorenzo benvenuti > Assignee: Lin Gao > Priority: Critical > Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final > > > Hi, > in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}: > {code:java} > public void cancel() throws SQLException > { > if (doLocking) > lock(); > try > { > /* ... */ > {code} > It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. > Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion. > Thank you, > lorenzo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1321) Statement.cancel() is not invoked until the statement is completed

by lorenzo benvenuti (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1321?page=com.atlassian.jira.plugin... ] lorenzo benvenuti commented on JBJCA-1321: ------------------------------------------ Hi, unfortunately this bug has became critical for our customers and we can't wait for a new version of Wildfly. We were thinking to proceed in this way: - Download sources for tag 1.2.5.Final (the version Wildfly 9.0.2 is using) - Apply patches from the PRs - Build a new jar and swap the original with it Should we perform some additional operation in order to be able to cancel the statement (such as enabling it in some configuration file or something like that)? Judging from the PRs I guess overwriting the jar should be enough but we want to be sure. Thank you, lorenzo > Statement.cancel() is not invoked until the statement is completed > ------------------------------------------------------------------ > > Key: JBJCA-1321 > URL: https://issues.jboss.org/browse/JBJCA-1321 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.4.Final, 1.2.7.Final > Reporter: lorenzo benvenuti > Assignee: Lin Gao > Priority: Critical > Fix For: WildFly/IronJacamar 1.3.5.Final, 1.2.8.Final > > > Hi, > in our application we are using the {{Statement.cancel()}} method to stop long-running queries; in Wildfly 9.0.2 this is not working because the {{cancel()}} method is synchronized using a lock which is not released until the query is executed. In {{WrappedStatement}}: > {code:java} > public void cancel() throws SQLException > { > if (doLocking) > lock(); > try > { > /* ... */ > {code} > It seems this behaviour has changed from version 1.2.5.Final of ironjacamar-jdbc; in version 1.2.4.Final {{WrappedStatement.cancel}} doesn't try to obtain the lock. > Probably I'm missing something, but to me it's strange that in order to cancel a statement you have to wait for its completion. > Thank you, > lorenzo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7031) Redirect Port Fails to Redirect to 3rd Party HTTP Port

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7031?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-7031. ----------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) Resolution: Rejected This is not an issue at all. It is just misconfiguration and nothing else. You need to configure secure port binding for http-listener so server knows to what https port to redirect if needed to. See "redirect-socket" config on http-listener I think easiest for you would be to just upgrade to WildFly 10.1.0.Final which by default comes with https-listener configured and also redirect ports. > Redirect Port Fails to Redirect to 3rd Party HTTP Port > ------------------------------------------------------ > > Key: WFLY-7031 > URL: https://issues.jboss.org/browse/WFLY-7031 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.CR1 > Reporter: Joe Carder > Assignee: Tomaz Cerar > Priority: Minor > > When setting a redirect socket to port not opened by Wildfly (IE: a port opened by Apache HTTPD or IIS), Wildfly throws the following exception: > ERROR [io.undertow.request] (default task-2) UT005001: An exception occurred processing the request: java.lang.IllegalStateException: UT010053: No confidential port is available to redirect the current request. > With the redirect socket to a port opened by JBoss, it works as expected. I'm not 100% sure this is a bug, or functional decision made for Wildfly 10 and is working as expected. However, in Previous Widlfly version (Widlfly 8) it was possible to set the redirect port to a third party service without out issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7260) Document in elytron model *-client-auth are mutual exclusive

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7260?page=com.atlassian.jira.plugin.... ] Jan Kalina commented on WFLY-7260: ---------------------------------- Yes, correct. If 'need' is true, value of 'want' is ignored. > Document in elytron model *-client-auth are mutual exclusive > ------------------------------------------------------------ > > Key: WFLY-7260 > URL: https://issues.jboss.org/browse/WFLY-7260 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Minor > > Add to documentation information that need-client-auth and want-client-auth are mutually exclusive. If one is set other is unset. > Now we just have: > * {{want-client-auth}} - "Set wantClientAuth on the underlying SSLContext - if a security domain is referenced this will automatically be set to true." > * {{need-client-auth}} - "Set needClientAuth on the underlying SSLContext." -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-118) Upgrade to WildFly Client Config 1.0.0.Beta1

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-118?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-118. ------------------------------------- Resolution: Done > Upgrade to WildFly Client Config 1.0.0.Beta1 > -------------------------------------------- > > Key: REMJMX-118 > URL: https://issues.jboss.org/browse/REMJMX-118 > Project: Remoting JMX > Issue Type: Component Upgrade > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha2 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-118) Upgrade to WildFly Client Config 1.0.0.Beta1

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-118: --------------------------------------- Summary: Upgrade to WildFly Client Config 1.0.0.Beta1 Key: REMJMX-118 URL: https://issues.jboss.org/browse/REMJMX-118 Project: Remoting JMX Issue Type: Component Upgrade Components: Build Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-117) Upgrade to WildFly Elytron 1.1.0.Beta10

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-117?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-117. ------------------------------------- Resolution: Done > Upgrade to WildFly Elytron 1.1.0.Beta10 > --------------------------------------- > > Key: REMJMX-117 > URL: https://issues.jboss.org/browse/REMJMX-117 > Project: Remoting JMX > Issue Type: Component Upgrade > Components: Build > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Alpha2 > > > Also add jboss threads 2.2.1.Final to test scope. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 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