April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11994) Hibernate ORM transformer method signature parameter comparison to treat Ljava/lang/Object as wildcard parameter

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11994?page=com.atlassian.jira.plugin... ] Scott Marlow commented on WFLY-11994: ------------------------------------- note that this addresses the problem mentioned on [https://issues.jboss.org/browse/WFLY-11991?focusedCommentId=13722538&page...] > Hibernate ORM transformer method signature parameter comparison to treat Ljava/lang/Object as wildcard parameter > ---------------------------------------------------------------------------------------------------------------- > > Key: WFLY-11994 > URL: https://issues.jboss.org/browse/WFLY-11994 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > > Replace the org.jboss.as.hibernate.Hibernate51CompatibilityTransformer check for Ljava/lang/Object, to instead match any object type (via custom code). Do the same for the MethodAdapter class. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ] Cheng Fang edited comment on WFLY-12031 at 4/30/19 12:54 PM: ------------------------------------------------------------- When adding to {{openFilePaths}} set, the file name part (the last element in the path) is used. So when removing it, we should also use the file name part of the path {{filePath}}. I think changing the remove line to the following should work (around line 272): {code:java} openFilePaths.remove(filePath.getFileName().toString()); {code} /cc [~flavia.rainone] was (Author: cfang): When adding to {{openFilePaths}} set, the file name part (the last element in the path) is used. So when removing it, we should also use the file name part of the path {{filePath}}. I think changing the remove line to the following should work: {code:java} openFilePaths.remove(filePath.getFileName().toString()); {code} /cc [~flavia.rainone] > Memory leak in wildfly transaction client > ----------------------------------------- > > Key: WFLY-12031 > URL: https://issues.jboss.org/browse/WFLY-12031 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 15.0.1.Final > Environment: wildfly-transaction-client-1.1.3.Final > wildfly.15.0.1.Final > Window 10 > Reporter: Joachim Petrich > Assignee: Cheng Fang > Priority: Critical > > After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used > {code:java} > XAResourceRegistryFile(Xid xid) throws SystemException { > xaRecoveryPath.toFile().mkdir(); // create dir if non existent > final String xidString = SimpleXid.of(xid).toHexString('_'); > this.filePath = xaRecoveryPath.resolve(xidString); > openFilePaths.add(*xidString*); > {code} > and for removing the entire file path: > {code:java} > protected void removeResource(XAResource resource) throws XAException { > if (resources.remove(resource)) { > if (resources.isEmpty()) { > // delete file > try { > if (fileChannel != null) { > fileChannel.close(); > } > Files.delete(filePath); > // deleting using the filepath as key caused a memory leak, > // if xid string have been added, therefore build the xid string for removing > openFilePaths.remove(*filePath.toString()*); > {code} > We didn't find any code where this xid are cleaned up. > As workaround we additionally extract the xid String from the file path and remove the corresponding entry. > {code:java} > String xidString = filePath.toString().substring(filePath.toString().indexOf( > xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1); > openFilePaths.remove(xidString); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12031) Memory leak in wildfly transaction client

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12031?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-12031: ----------------------------------- When adding to {{openFilePaths}} set, the file name part (the last element in the path) is used. So when removing it, we should also use the file name part of the path {{filePath}}. I think changing the remove line to the following should work: {code:java} openFilePaths.remove(filePath.getFileName().toString()); {code} /cc [~flavia.rainone] > Memory leak in wildfly transaction client > ----------------------------------------- > > Key: WFLY-12031 > URL: https://issues.jboss.org/browse/WFLY-12031 > Project: WildFly > Issue Type: Bug > Components: Transactions > Affects Versions: 15.0.1.Final > Environment: wildfly-transaction-client-1.1.3.Final > wildfly.15.0.1.Final > Window 10 > Reporter: Joachim Petrich > Assignee: Cheng Fang > Priority: Critical > > After a volume run of our system we recognized millions of entries in the openFilePaths Object of class FileSystemXAResourceRegistry. When enabling traces for org.wildfly.transaction it seems that for adding an entry a xid string is used > {code:java} > XAResourceRegistryFile(Xid xid) throws SystemException { > xaRecoveryPath.toFile().mkdir(); // create dir if non existent > final String xidString = SimpleXid.of(xid).toHexString('_'); > this.filePath = xaRecoveryPath.resolve(xidString); > openFilePaths.add(*xidString*); > {code} > and for removing the entire file path: > {code:java} > protected void removeResource(XAResource resource) throws XAException { > if (resources.remove(resource)) { > if (resources.isEmpty()) { > // delete file > try { > if (fileChannel != null) { > fileChannel.close(); > } > Files.delete(filePath); > // deleting using the filepath as key caused a memory leak, > // if xid string have been added, therefore build the xid string for removing > openFilePaths.remove(*filePath.toString()*); > {code} > We didn't find any code where this xid are cleaned up. > As workaround we additionally extract the xid String from the file path and remove the corresponding entry. > {code:java} > String xidString = filePath.toString().substring(filePath.toString().indexOf( > xaRecoveryPath.toString()) + xaRecoveryPath.toString().length() + 1); > openFilePaths.remove(xidString); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3849) Different default with property reactivity with DRL and Exec Model

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3849?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-3849. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/aa986a57724e2f16cabea9c084b8e16... > Different default with property reactivity with DRL and Exec Model > ------------------------------------------------------------------ > > Key: DROOLS-3849 > URL: https://issues.jboss.org/browse/DROOLS-3849 > Project: Drools > Issue Type: Enhancement > Components: executable model > Affects Versions: 7.20.0.Final > Reporter: Luca Molteni > Assignee: Mario Fusco > Priority: Major > > This test > Regression3800Test.testPropertyReactivityHanging > loop forever while using the executable model because of the default in property reactivity BitMask (0 vs MAX_LONG) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection

by Stephen Fikes (Jira)

[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ] Stephen Fikes commented on JBJCA-1389: -------------------------------------- The root cause seems to be that, unlike other code paths, there is no {{checkStatus()}} call prior to the execution of {{mc.getRealConnection()}} in {{getWrappedObject()}}. > NullPointerException raised when calling isWrapperFor(...) on a closed connection > --------------------------------------------------------------------------------- > > Key: JBJCA-1389 > URL: https://issues.jboss.org/browse/JBJCA-1389 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.4.9 > Reporter: Stephen Fikes > Priority: Major > > When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." > {code} > ... java.lang.NullPointerException > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) > at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection

by Stephen Fikes (Jira)

[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ] Stephen Fikes updated JBJCA-1389: --------------------------------- Description: When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." {code} ... java.lang.NullPointerException at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) {code} The NPE obscures the usage issue. was: When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." {code} ... java.lang.NullPointerException at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) {code} > NullPointerException raised when calling isWrapperFor(...) on a closed connection > --------------------------------------------------------------------------------- > > Key: JBJCA-1389 > URL: https://issues.jboss.org/browse/JBJCA-1389 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.4.9 > Reporter: Stephen Fikes > Priority: Major > > When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." > {code} > ... java.lang.NullPointerException > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) > at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) > {code} > The NPE obscures the usage issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection

by Stephen Fikes (Jira)

[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ] Stephen Fikes updated JBJCA-1389: --------------------------------- Description: When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed (i.e. returned to the pool, managed connection disassociated) previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." {code} ... java.lang.NullPointerException at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) {code} The NPE obscures the usage issue. was: When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." {code} ... java.lang.NullPointerException at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) {code} The NPE obscures the usage issue. > NullPointerException raised when calling isWrapperFor(...) on a closed connection > --------------------------------------------------------------------------------- > > Key: JBJCA-1389 > URL: https://issues.jboss.org/browse/JBJCA-1389 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.4.9 > Reporter: Stephen Fikes > Priority: Major > > When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed (i.e. returned to the pool, managed connection disassociated) previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." > {code} > ... java.lang.NullPointerException > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) > at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) > {code} > The NPE obscures the usage issue. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection

by Stephen Fikes (Jira)

[ https://issues.jboss.org/browse/JBJCA-1389?page=com.atlassian.jira.plugin... ] Stephen Fikes updated JBJCA-1389: --------------------------------- Description: When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." {code} ... java.lang.NullPointerException at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) {code} was: When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException }} is raised. The exception should be "Connection is not associated with a managed connection: ..." {code} ... java.lang.NullPointerException at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) {code} > NullPointerException raised when calling isWrapperFor(...) on a closed connection > --------------------------------------------------------------------------------- > > Key: JBJCA-1389 > URL: https://issues.jboss.org/browse/JBJCA-1389 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: 1.4.9 > Reporter: Stephen Fikes > Priority: Major > > When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException}} is raised. The exception should be "Connection is not associated with a managed connection: ..." > {code} > ... java.lang.NullPointerException > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) > at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) > at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1389) NullPointerException raised when calling isWrapperFor(...) on a closed connection

by Stephen Fikes (Jira)

Stephen Fikes created JBJCA-1389: ------------------------------------ Summary: NullPointerException raised when calling isWrapperFor(...) on a closed connection Key: JBJCA-1389 URL: https://issues.jboss.org/browse/JBJCA-1389 Project: IronJacamar Issue Type: Bug Components: JDBC Affects Versions: 1.4.9 Reporter: Stephen Fikes When calling {{Connection.isWrapperFor(...)}} on a connection which has been closed previously, a {{NullPointerException }} is raised. The exception should be "Connection is not associated with a managed connection: ..." {code} ... java.lang.NullPointerException at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:1914) at org.jboss.jca.adapters.jdbc.WrappedConnection.getWrappedObject(WrappedConnection.java:64) at org.jboss.jca.adapters.jdbc.JBossWrapper.isWrapperFor(JBossWrapper.java:68) {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3850) Pattern DSL not evaluating with two constraints

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3850?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3850: -------------------------------- Sprint: 2019 Week 17-19 > Pattern DSL not evaluating with two constraints > ----------------------------------------------- > > Key: DROOLS-3850 > URL: https://issues.jboss.org/browse/DROOLS-3850 > Project: Drools > Issue Type: Bug > Affects Versions: 7.20.0.Final > Reporter: Luca Molteni > Assignee: Mario Fusco > Priority: Major > > See CompilerTest.testErrorTwoPatterns ignored test -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 5 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 April 2019