October 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2206) Manualmode test suite copes the modules directory multiple times

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2206?page=com.atlassian.jira.plugin.... ] Tomaz Cerar resolved WFLY-2206. ------------------------------- Assignee: Stuart Douglas (was: Tomaz Cerar) Fix Version/s: 8.0.0.Beta1 Resolution: Done > Manualmode test suite copes the modules directory multiple times > ---------------------------------------------------------------- > > Key: WFLY-2206 > URL: https://issues.jboss.org/browse/WFLY-2206 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 8.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.0.0.Beta1 > > > This uses lots of disk space for no good reason -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-282) Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context

by Marco Rietveld (JIRA)

[ https://issues.jboss.org/browse/DROOLS-282?page=com.atlassian.jira.plugin... ] Marco Rietveld updated DROOLS-282: ---------------------------------- Attachment: app-scoped-em-race-condition-example.txt Added a stack trace that illustrates the race-condition. > Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context > ------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-282 > URL: https://issues.jboss.org/browse/DROOLS-282 > Project: Drools > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 6.0.0.Final > Reporter: Marco Rietveld > Assignee: Marco Rietveld > Attachments: app-scoped-em-race-condition-example.txt > > > The application scoped persistence context ({{EntityManager}}) causes a race-condition when a persistence KieSession is accessed by multiple threads in which the transaction is _*not*_ managed by the {{KieSession}} but by code outside of the drools/jbpm/kie code base. > A "{{CommandSessionCommandService}}" implementation would work very similarly to the existing {{SingleSessionCommandService}} implementation: in both implementations, each thread would use it's own command scoped entity manager. > However, the {{CommandSessionCommandService}} would *not* use an {{EntityManager}} that would be used by multiple threads. > The race-condition that arises due to the use of an application scoped entity manager is due to the following: > - The JPA spec clearly states that the {{EntityManager}} is not thread-safe. > - As a result of this Hibernate (and probably other ORM frameworks) only has one internal object to represent whether or not the {{EntityManager(Impl)}} has joined a transaction or not. > - For JTA, Hibernate uses the JTA Synchronization mechanism (normal, not interposed) in order to reset this status once a transaction has committed. > - When one thread calls {{tx.commit()}} while another thread calls {{em.joinTransaction()}}, then a race-condition can happen in which the "joined transaction" status is first set by the {{EntityManager.joinTransaction()}} call _after which the status is reset to *not-joined* by the Hibernate injected JTA Synchronization instance in it's {{afterCompletion(..)}} method)_. > Occasionally, the call to {{EntityManager.joinTransaction()}} will fail because of this race-condtion, although the more dangerous situation is one in which {{.joinTransaction()}} does not throw an exception but where the race-condition does happen. > I've made a trivial effort to create this implementation and discovered that it's more difficult than I had initially expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2176) JSF should be able to access the CDI-enabled ValidatorFactory

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-2176?page=com.atlassian.jira.plugin.... ] Farah Juma commented on WFLY-2176: ---------------------------------- Created the following pull request: https://github.com/wildfly/wildfly/pull/5212 > JSF should be able to access the CDI-enabled ValidatorFactory > ------------------------------------------------------------- > > Key: WFLY-2176 > URL: https://issues.jboss.org/browse/WFLY-2176 > Project: WildFly > Issue Type: Feature Request > Components: JSF > Affects Versions: 8.0.0.Alpha4 > Reporter: Farah Juma > Assignee: Farah Juma > > Currently, for every deployment that uses JSF, the JSF subsystem adds the org.hibernate.validator module to the deployment. A ValidatorFactory is then obtained via the standard Bean Validation bootstrap strategy. However, a ValidatorFactory obtained this way isn't CDI-enabled. JSF needs to use the EE LazyValidatorFactory instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-282) Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context

by Marco Rietveld (JIRA)

Marco Rietveld created DROOLS-282: ------------------------------------- Summary: Create a "CommandSessionCommandService" implementation that does not use an application-scoped persistence context Key: DROOLS-282 URL: https://issues.jboss.org/browse/DROOLS-282 Project: Drools Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: Marco Rietveld Assignee: Marco Rietveld The application scoped persistence context ({{EntityManager}}) causes a race-condition when a persistence KieSession is accessed by multiple threads in which the transaction is _*not*_ managed by the {{KieSession}} but by code outside of the drools/jbpm/kie code base. A "{{CommandSessionCommandService}}" implementation would work very similarly to the existing {{SingleSessionCommandService}} implementation: in both implementations, each thread would use it's own command scoped entity manager. However, the {{CommandSessionCommandService}} would *not* use an {{EntityManager}} that would be used by multiple threads. The race-condition that arises due to the use of an application scoped entity manager is due to the following: - The JPA spec clearly states that the {{EntityManager}} is not thread-safe. - As a result of this Hibernate (and probably other ORM frameworks) only has one internal object to represent whether or not the {{EntityManager(Impl)}} has joined a transaction or not. - For JTA, Hibernate uses the JTA Synchronization mechanism (normal, not interposed) in order to reset this status once a transaction has committed. - When one thread calls {{tx.commit()}} while another thread calls {{em.joinTransaction()}}, then a race-condition can happen in which the "joined transaction" status is first set by the {{EntityManager.joinTransaction()}} call _after which the status is reset to *not-joined* by the Hibernate injected JTA Synchronization instance in it's {{afterCompletion(..)}} method)_. Occasionally, the call to {{EntityManager.joinTransaction()}} will fail because of this race-condtion, although the more dangerous situation is one in which {{.joinTransaction()}} does not throw an exception but where the race-condition does happen. I've made a trivial effort to create this implementation and discovered that it's more difficult than I had initially expected. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2212) Update JPA subsystem to use default EE datasource binding

by Scott Marlow (JIRA)

Scott Marlow created WFLY-2212: ---------------------------------- Summary: Update JPA subsystem to use default EE datasource binding Key: WFLY-2212 URL: https://issues.jboss.org/browse/WFLY-2212 Project: WildFly Issue Type: Task Components: JPA / Hibernate Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 8.0.0.Beta1 JPA subsystem should check if a default EE datasource binding is available to use and default to that if a persistence unit doesn't specify a datasource. Also add a persistence unit hint to not use a default datasource (might be helpful for OGM which fails the deployment if a datasource is specified). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2211) NullPointerException in RemotingHttpUpgradeService is no http port.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-2211: -------------------------------------- Summary: NullPointerException in RemotingHttpUpgradeService is no http port. Key: WFLY-2211 URL: https://issues.jboss.org/browse/WFLY-2211 Project: WildFly Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 8.0.0.Beta1 Starting with a HTTP port is not mandatory. {code} Caused by: java.lang.NullPointerException at org.jboss.as.remoting.RemotingHttpUpgradeService.start(RemotingHttpUpgradeService.java:107) [wildfly-remoting-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2211) NullPointerException in RemotingHttpUpgradeService if no http port.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2211?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-2211: ----------------------------------- Summary: NullPointerException in RemotingHttpUpgradeService if no http port. (was: NullPointerException in RemotingHttpUpgradeService is no http port.) > NullPointerException in RemotingHttpUpgradeService if no http port. > ------------------------------------------------------------------- > > Key: WFLY-2211 > URL: https://issues.jboss.org/browse/WFLY-2211 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > Starting with a HTTP port is not mandatory. > {code} > Caused by: java.lang.NullPointerException > at org.jboss.as.remoting.RemotingHttpUpgradeService.start(RemotingHttpUpgradeService.java:107) [wildfly-remoting-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2] > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2207) CLI Unable to connect using https-remoting address.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-2207?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-2207: ---------------------------------------- With TRACE logging enabled the CLI appears to be stuck in an infinate loop for 5 seconds repeating the following each time: - {code} 14:41:37,014 TRACE [org.xnio.nio.selector] Beginning select on sun.nio.ch.EPollSelectorImpl@474906b9 14:41:37,015 TRACE [org.xnio.nio.selector] Selected on sun.nio.ch.EPollSelectorImpl@474906b9 14:41:37,015 TRACE [org.xnio.nio.selector] Selected key sun.nio.ch.SelectionKeyImpl@187feca0 for java.nio.channels.SocketChannel[connected local=/127.0.0.1:50836 remote=localhost/127.0.0.1:9993] 14:41:37,015 TRACE [org.xnio.listener] Invoking listener org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener@20a12d8f on channel org.xnio.conduits.ConduitStreamSourceChannel@35b61805 {code} > CLI Unable to connect using https-remoting address. > --------------------------------------------------- > > Key: WFLY-2207 > URL: https://issues.jboss.org/browse/WFLY-2207 > Project: WildFly > Issue Type: Bug > Components: CLI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 8.0.0.Beta1 > > > The CLI is failing to connect over https with the following: - > {code} > [disconnected /] connect https-remoting://localhost:9993 > The controller is not available at localhost:9993: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of Transaction isn't stable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1070: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608] Fixed in EAP 6.2.0.ER1. > Memory leak if hashCode of Transaction isn't stable > --------------------------------------------------- > > Key: JBJCA-1070 > URL: https://issues.jboss.org/browse/JBJCA-1070 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.20.Final, 1.1.1.Final > > > Happens in TransactionSynchronizer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1070) Memory leak if hashCode of Transaction isn't stable

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1070?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1070: ------------------------------------------------ Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1007608|https://bugzilla.redhat.com/show_bug.cgi?id=1007608] from NEW to ON_QA > Memory leak if hashCode of Transaction isn't stable > --------------------------------------------------- > > Key: JBJCA-1070 > URL: https://issues.jboss.org/browse/JBJCA-1070 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.19.Final, 1.1.0.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Priority: Critical > Fix For: 1.0.20.Final, 1.1.1.Final > > > Happens in TransactionSynchronizer -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

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