February 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6582) Classloader leaking in JPA module

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/AS7-6582?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-6582: ----------------------------------- Hi Brian, great to see you here, since we both love chasing down these types of leaks. ;) I saw the picture, which looks to show some storage associated with what is probably the EntityManagerFactory that the persistence unit service creates. And the EntityManagerFactory would still reference the SerializableValidatorFactory (I'm not surprised by that). I'm also not against the proposed patch if it resolves the entire memory leak but I'm still wondering why the reference to the EntityManagerFactory didn't get cleaned up. Scott > Classloader leaking in JPA module > --------------------------------- > > Key: AS7-6582 > URL: https://issues.jboss.org/browse/AS7-6582 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Environment: Fedora 17, Oracle jdk 7u9 > CentOS 6.3, Oracle jdk 7u11 > Reporter: Brent Douglas > Assignee: Scott Marlow > > PersistenceUnitServiceHandler retains references to deployment classes after the service is stopped through SerializableValidatorFactory. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-5424) string-keyed-jdbc-store datasource configuration

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/AS7-5424?page=com.atlassian.jira.plugin.s... ] Paul Ferraro closed AS7-5424. ----------------------------- Resolution: Out of Date This is no longer an issue. We have an integration test that verifies use of a jdbc cache store and uses the "java:jboss" namespace without issue. > string-keyed-jdbc-store datasource configuration > ------------------------------------------------ > > Key: AS7-5424 > URL: https://issues.jboss.org/browse/AS7-5424 > Project: Application Server 7 > Issue Type: Bug > Components: Clustering > Environment: mac osx 10.6.8, JDK 1.6.0_33 > Reporter: Brian Wallis > Assignee: Paul Ferraro > > The following cache store configuration > <cache-container name="modeshapeCache" default-cache="default"> > <local-cache name="testRepositoryCache"> > <transaction mode="FULL_XA"/> > <string-keyed-jdbc-store datasource="java:jboss/datasources/JcrDataDS"/> > </local-cache> > </cache-container> > quietly fails and when a cache of name testRepositoryCache is returned from container.getCache("testRepositoryCache") a default cache is returned rather than the one configured in the standalone.xml file. > Removing the java: makes this work, the JNDI name is then resolved and the JDBC based cache loader is configured correctly. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6582) Classloader leaking in JPA module

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-6582?page=com.atlassian.jira.plugin.s... ] Brian Stansberry commented on AS7-6582: --------------------------------------- Scott, I see that the pull request description has a screenshot from some tool showing a reference chain. > Classloader leaking in JPA module > --------------------------------- > > Key: AS7-6582 > URL: https://issues.jboss.org/browse/AS7-6582 > Project: Application Server 7 > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 7.1.3.Final (EAP) > Environment: Fedora 17, Oracle jdk 7u9 > CentOS 6.3, Oracle jdk 7u11 > Reporter: Brent Douglas > Assignee: Scott Marlow > > PersistenceUnitServiceHandler retains references to deployment classes after the service is stopped through SerializableValidatorFactory. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6548) To add salve node dynamicaly

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/AS7-6548?page=com.atlassian.jira.plugin.s... ] Paul Ferraro commented on AS7-6548: ----------------------------------- This doesn't seem to be a clustering issue, but rather a domain controller issue. Have you tried this with the latest 7.1.x release? > To add salve node dynamicaly > ---------------------------- > > Key: AS7-6548 > URL: https://issues.jboss.org/browse/AS7-6548 > Project: Application Server 7 > Issue Type: Clarification > Components: Clustering, ConfigAdmin, Domain Management, Server > Affects Versions: 7.0.2.Final > Environment: Linux , jboss-as-web-7.0.2.Final > Reporter: hitesh yadav > Assignee: Paul Ferraro > Labels: jboss > > Once cluster(domain) is created and if we have deploy .war in cluster after that if we try to add new slave node cluster become unstable. > We are not able to disable/remove .war from domain controller and also from slave . -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ] James Perkins commented on AS7-6583: ------------------------------------ I wouldn't say it's a bug or an issue with the logging subsystem. While the change may have become visible with a change in the logging subsystem, it's more than likely some piece of code is doing too many {{Logger.getLogger()}} invocations. It could be Weld, it could be something else. The toughest part will probably be figuring out what it is, but a profiler would likely lead to a clue. > Performance regression comparing to previous release > ---------------------------------------------------- > > Key: AS7-6583 > URL: https://issues.jboss.org/browse/AS7-6583 > Project: Application Server 7 > Issue Type: Bug > Components: CDI / Weld, Logging > Affects Versions: 7.2.0.Alpha1 > Environment: 7.2.0.Final (prerelease-1 tag) > Reporter: Tomas Remes > Assignee: James Perkins > Priority: Critical > Labels: performance > > There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6583) Performance regression comparing to previous release

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/AS7-6583?page=com.atlassian.jira.plugin.s... ] Tomas Remes commented on AS7-6583: ---------------------------------- JSF was the first thing, which came to my mind, but it didn't show any crucial impact. Then I start slow and annoying work with "git bisect" and that brings me to commits to logging subsystem. > Performance regression comparing to previous release > ---------------------------------------------------- > > Key: AS7-6583 > URL: https://issues.jboss.org/browse/AS7-6583 > Project: Application Server 7 > Issue Type: Bug > Components: CDI / Weld, Logging > Affects Versions: 7.2.0.Alpha1 > Environment: 7.2.0.Final (prerelease-1 tag) > Reporter: Tomas Remes > Assignee: James Perkins > Priority: Critical > Labels: performance > > There is significant performance regression in 7.2.0 prerelease. I discovered it in my Weld performance load tests (testing simple Weld numberguess example application), but I am quite sure that's not Weld issue at all. I did some investigations and it seems that problem occurred in org/jboss/as/logging module. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6587) Use JBoss Logging for resource adapter LogWriter

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/AS7-6587?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on AS7-6587: ---------------------------------- Do RARs respect {{<module-name>}} declarations? If so, it should probably log using that name to avoid things like Maven version #s in log categories. Also I'd forego the ".rar" extension as it's just goofy and weird (and presumably there will be other ways to tell that the log message is RAR-related). > Use JBoss Logging for resource adapter LogWriter > ------------------------------------------------ > > Key: AS7-6587 > URL: https://issues.jboss.org/browse/AS7-6587 > Project: Application Server 7 > Issue Type: Task > Components: JCA > Reporter: Jesper Pedersen > Assignee: Stefano Maestri > > Have each resource adapter deployment use JBoss Logging for its LogWriter implementation. > Logging category should include the resource adapter name (eis.rar), and activation id. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6460) Attribute check-for-live-server must set on live server to faillback

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6460?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6460: ---------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> made a comment on [bug 908261|https://bugzilla.redhat.com/show_bug.cgi?id=908261] After discussion with dev it was agreed that this is a feature. Can it be documented in EAP 6 doc? PR: https://github.com/FranciscoBorges/hornetq/commit/8d828124365a5f4de236d62... This is a feature which was documented in above pull request. Assigning bz to doc team. > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: AS7-6460 > URL: https://issues.jboss.org/browse/AS7-6460 > Project: Application Server 7 > Issue Type: Task > Components: JMS > Affects Versions: 7.2.0.Alpha1 > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 7.2.0.CR1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6460) Attribute check-for-live-server must set on live server to faillback

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6460?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6460: ---------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> changed the Status of [bug 908261|https://bugzilla.redhat.com/show_bug.cgi?id=908261] from ON_QA to ASSIGNED > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: AS7-6460 > URL: https://issues.jboss.org/browse/AS7-6460 > Project: Application Server 7 > Issue Type: Task > Components: JMS > Affects Versions: 7.2.0.Alpha1 > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 7.2.0.CR1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-6460) Attribute check-for-live-server must set on live server to faillback

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6460?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6460: ---------------------------------------------- Miroslav Novak <mnovak(a)redhat.com> made a comment on [bug 908261|https://bugzilla.redhat.com/show_bug.cgi?id=908261] PR for HornetQ doc: https://github.com/FranciscoBorges/hornetq/commit/8d828124365a5f4de236d62... Moving bz to ON_QA status for later verification. > Attribute check-for-live-server must set on live server to faillback > -------------------------------------------------------------------- > > Key: AS7-6460 > URL: https://issues.jboss.org/browse/AS7-6460 > Project: Application Server 7 > Issue Type: Task > Components: JMS > Affects Versions: 7.2.0.Alpha1 > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Fix For: 7.2.0.CR1 > > Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml > > > When there is live/backup pair with replicated journal then it should be sufficient to set attribute "check-for-live-server" in messaging subsystem only on backup to force backup server to shutdown when live server comes alive again. Problem is this won't happen. > Only when attribute "check-for-live-server" is set on live server then failback is successful (backup shutdown itself) > It's not well documented where "check-for-live-server" should be set in HornetQ project documentation: > http://docs.jboss.org/hornetq/2.3.0.CR1/docs/user-manual/html_single/inde... > This issue was hit with EAP 6.1.0.DR2 (HQ 2.3.0.CR1). -- 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

13 years, 2 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 February 2013