April 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-922) Handle merging of clustered SFSB state if a MergeView is received

by Brian Stansberry (JIRA)

Handle merging of clustered SFSB state if a MergeView is received ----------------------------------------------------------------- Key: EJBTHREE-922 URL: http://jira.jboss.com/jira/browse/EJBTHREE-922 Project: EJB 3.0 Issue Type: Task Components: Clustering Affects Versions: AS 4.2.0 CR1 Reporter: Brian Stansberry Assigned To: Brian Stansberry The JBCACHE-8 solution will provide a notification of when a cluster merge occurs. Need to work with the JBC team to design the callback and to implement a solution that will allow merging of clustered SFSB state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-895) Allow clustered tests to run with -u set

by Brian Stansberry (JIRA)

Allow clustered tests to run with -u set ---------------------------------------- Key: EJBTHREE-895 URL: http://jira.jboss.com/jira/browse/EJBTHREE-895 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Need to use the local.properties "udpGroup" stuff that the AS uses. Allows running with less concern for impactt from / impacting other running servers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-857) Include and use buddy group topology information in clustered SFSB proxies

by Brian Stansberry (JIRA)

Include and use buddy group topology information in clustered SFSB proxies -------------------------------------------------------------------------- Key: EJBTHREE-857 URL: http://jira.jboss.com/jira/browse/EJBTHREE-857 Project: EJB 3.0 Issue Type: Feature Request Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Look into including the replicated SFSB cache's buddy replication group topology in clustered SFSB proxies, and using that information in fail over decisions. This is basically an optimization such that when a failover occurs, data gravitation can occur in VM rather than over the network. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-848) ClusteredStatefulCacheListener should be a singleton

by Brian Stansberry (JIRA)

ClusteredStatefulCacheListener should be a singleton ---------------------------------------------------- Key: EJBTHREE-848 URL: http://jira.jboss.com/jira/browse/EJBTHREE-848 Project: EJB 3.0 Issue Type: Task Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: EJB 3.0 RC11 - FD Currently, each SFSB Container registers an instance of ClusteredStatefulCacheListener with the SFSB cache. This is inefficient if there are many containers, as each gets passivation/activation callbacks and has to filter for the ones it's interested in. The callbacks don't do anything container-specific, so it should be possible to use a quasi-singleton ClusteredStatefulCacheListener and eliminate the filtering. Quasi-singleton, because it's possible to have multiple SFSB caches; need one listener per cache. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

3
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-845) Clarify transactional behavior of clustered SFSB cache

by Brian Stansberry (JIRA)

Clarify transactional behavior of clustered SFSB cache ------------------------------------------------------ Key: EJBTHREE-845 URL: http://jira.jboss.com/jira/browse/EJBTHREE-845 Project: EJB 3.0 Issue Type: Task Components: Clustering Affects Versions: EJB 3.0 RC9 - Patch 1, EJB 3.0 RC9 - FD Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: EJB 3.0 RC10 - FD The ejb3-clustered-sfsb-service.xml is not declaring a TransactionManagerLookupClass, so the cache is not transactional. Need to clarify why this is and correct if there is no good reason. If it is valid, work with JBC team to eliminate the WARN JBC logs when no lookup is specified. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1053) State changes in @PrePassivate don't get replicated if passivate before replication is disabled

by Carlo de Wolf (JIRA)

State changes in @PrePassivate don't get replicated if passivate before replication is disabled ----------------------------------------------------------------------------------------------- Key: EJBTHREE-1053 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1053 Project: EJB 3.0 Issue Type: Bug Components: Clustering Affects Versions: AS 4.2.2.GA Reporter: Carlo de Wolf Passivation doesn't trigger replication, so a bean might get passivated on 1 node and not on another. If the bean provider does state changes in pre-passivate these will not be visible on the other node. By default replication does trigger passivation, so a bean first gets passivated and then replicated. Thus the problem only occurs if passivate before replication is explicitly disabled. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1054) Buddy replication can lead to a memory leak

by Carlo de Wolf (JIRA)

Buddy replication can lead to a memory leak ------------------------------------------- Key: EJBTHREE-1054 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1054 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.2.GA Reporter: Carlo de Wolf JBC passivation code is broken with buddy replication enabled. Whenever a bean is replicated it's copied to a backup region. This backup region is never evicted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1177) dependency on JMSProviderAdapter

by Andy Taylor (JIRA)

dependency on JMSProviderAdapter -------------------------------- Key: JBMESSAGING-1177 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1177 Project: JBoss Messaging Issue Type: Sub-task Components: Messaging Core Affects Versions: 2.0.0 Alpha Reporter: Andy Taylor Assigned To: Andy Taylor Fix For: 2.0.0 Alpha currently we have a dependency on JMSProviderAdapter. This, at the present, is in jbossas core which we shouldnt be dependant on. This either needs moving to the integration project or we need to rethink how it works. This is currently used in The XAMessagingResourceWrapper -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 5 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-146) Clustered EJB setting at the application level (EAR)

by Galder Zamarreno (JIRA)

Clustered EJB setting at the application level (EAR) ---------------------------------------------------- Key: JBCLUSTER-146 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-146 Project: JBoss Clustering Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assigned To: Brian Stansberry We are using clustering for tests. Our application is an ear-archive which has no information about clustering. If we will built up a cluster, we have to change the ejb-jar.xml to set the clustered-tag on True. This is very intricate. Out support team have to unpack the ear - set the clustered-tag for every bean and so on. Is it possible to set the clustered-tag all beans in a ear-Archive? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
8
0 / 0

[JBoss JIRA] Created: (JBAS-5300) ClassLoader leaks in TimedCachePolicy through JAAS Auth Cache

by Arto Huusko (JIRA)

ClassLoader leaks in TimedCachePolicy through JAAS Auth Cache ------------------------------------------------------------- Key: JBAS-5300 URL: http://jira.jboss.com/jira/browse/JBAS-5300 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: ClassLoading Affects Versions: JBossAS-4.2.1.GA Environment: JDK 1.6.0_04 Reporter: Arto Huusko Assigned To: Scott M Stark JAAS authentication cache is responsible for two classloader leaks through org.jboss.utils.TimedCachePolicy, causing classes of undeployed applications not be unloaded. The second is not a huge problem, but still real, and is related to JBAS-3986. First problem is the creation of resolutionTimer. If TimedCachePolicy is used for the first time when my web application is accessed, the resolutionTimer object is created in the context of the web app, and the timer thread attached to the timer inherits the current context class loader, that is my web app's class loader. This results in a permanent reference to that class loader, and it can never be unloaded. The second problem is the fact that the expired entries are purged from the cache only when they are accessed. If some credentials are once used, and then never used again, they remain in the cache, and these cached LoginContexts contain references to the web app class loaders. First problem is fixable by temporarily changing current thread context class loader when first creating the resolutionTimer. The second problem could be fixed by JBoss automatically flushing the authentication cache when the web app is undeployed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2008