July 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAOP-431) Avoid excessive casting in generated joinpoint classes

by Kabir Khan (JIRA)

Avoid excessive casting in generated joinpoint classes ------------------------------------------------------ Key: JBAOP-431 URL: http://jira.jboss.com/jira/browse/JBAOP-431 Project: JBoss AOP Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan -- 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

17 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1515) Execute permissions removed while building the jboss-portal src distro

by Rajesh Rajasekaran (JIRA)

Execute permissions removed while building the jboss-portal src distro ---------------------------------------------------------------------- Key: JBPORTAL-1515 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1515 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6 CR3 Reporter: Rajesh Rajasekaran Assigned To: Julien Viet Fix For: 2.6 Final A temporary copy of the portal src is made to the build/output directory before the src distro is created. This ant copy task in distrib.xml removes all execute permissions on .sh files, the ant executable packaged etc. Trying to build from the src distro says [rrajasekaran@dev03 build]$ sh build.sh build.sh: *WARNING* Ignoring environment value for $ANT_HOME build.sh: *FATAL* Ant script is not executable: /home/rrajasekaran/jboss-portal-2.6-CR3-src/tools/bin/ant The ant manual says "Unix Note: File permissions are not retained when files are copied; they end up with the default UMASK permissions instead. This is caused by the lack of any means to query or set file permissions in the current Java runtimes." Either the build needs to be modified or i can try something with the UMASK settings while building. -- 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

17 years, 2 months

3
7
0 / 0

[JBoss JIRA] Commented: (JBCACHE-486) Optimize activations

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-486?page=comments#action_12368889 ] Manik Surtani commented on JBCACHE-486: --------------------------------------- Not necessary anymore since we test node.isDataLoaded() to gain the same info. The loader.exists() call is unnecessary and has been removed. > Optimize activations > -------------------- > > Key: JBCACHE-486 > URL: http://jira.jboss.com/jira/browse/JBCACHE-486 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Jerry Gauthier > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.0.0.GA > > > JBCACHE-420 notes that activation processing is performed excessively. The resolution of JBCACHE-420 eliminates the excessive activations but it doesn't resolve the following optimization issue. > The ActivationInterceptor can't readily determine whether a node has been passivated because the cache loading operation occurs in the CacheLoaderInterceptor. Consequently the activation interceptor invokes loader.exists(node) to ascertain whether the node has been passivated. This works properly but is an unnecessary operation as the CacheLoader interceptor executes immediately prior to the Activation interceptor and it makes a similar determination. This determination can be expensive as itmay involve performing database operations (e.g., for a JDBC cache loader). > It's desirable to eliminate the loader.exists(node) invocation in the Activation interceptor to optimize performance. One possible way to accomplish this would be to add a pesudo attribute __PASSIVATED__ > to the node's hashmap (similar to __INITIALIZED__) whenever a node has been passivated, and remove it again when > activated. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-486) Optimize activations

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-486?page=all ] Manik Surtani closed JBCACHE-486. --------------------------------- Resolution: Done > Optimize activations > -------------------- > > Key: JBCACHE-486 > URL: http://jira.jboss.com/jira/browse/JBCACHE-486 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Jerry Gauthier > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.0.0.GA > > > JBCACHE-420 notes that activation processing is performed excessively. The resolution of JBCACHE-420 eliminates the excessive activations but it doesn't resolve the following optimization issue. > The ActivationInterceptor can't readily determine whether a node has been passivated because the cache loading operation occurs in the CacheLoaderInterceptor. Consequently the activation interceptor invokes loader.exists(node) to ascertain whether the node has been passivated. This works properly but is an unnecessary operation as the CacheLoader interceptor executes immediately prior to the Activation interceptor and it makes a similar determination. This determination can be expensive as itmay involve performing database operations (e.g., for a JDBC cache loader). > It's desirable to eliminate the loader.exists(node) invocation in the Activation interceptor to optimize performance. One possible way to accomplish this would be to add a pesudo attribute __PASSIVATED__ > to the node's hashmap (similar to __INITIALIZED__) whenever a node has been passivated, and remove it again when > activated. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-572) Add clustering stress tests

by Tim Fox (JIRA)

Add clustering stress tests --------------------------- Key: JBMESSAGING-572 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-572 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta1 -- 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

17 years, 2 months

6
12
0 / 0

[JBoss JIRA] Closed: (JBCACHE-562) Disable cache loader when no cacheloader class is specified

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-562?page=all ] Manik Surtani closed JBCACHE-562. --------------------------------- Resolution: Rejected I don't think we should disable cache loaders based on the class being configured being an empty string or a null. > Disable cache loader when no cacheloader class is specified > ----------------------------------------------------------- > > Key: JBCACHE-562 > URL: http://jira.jboss.com/jira/browse/JBCACHE-562 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.0.0.GA > > > In 1.3, we support a new form of cacheloader config. However, it is incovenient to disable the cache loader (previously all we need is to specify cacheloaderclass to empty). We should also support this kind of semantics so we can disable it easily. I propose when do createcacheloader, we also check whether the class name is there or not to decide whether to go ahead. If not, we simply log an info message. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-533) Remove synchronization in Passivation/Activation interceptor

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-533?page=all ] Manik Surtani updated JBCACHE-533: ---------------------------------- Summary: Remove synchronization in Passivation/Activation interceptor (was: Change synchronization to use locks in Passivation/Activation interceptor) Description: This is now handled in the cache loader implementation (was: Re synchronization in PassivationInterceptor and ActivationInterceptor The synchronization statement is needed to prevent multiple threads from trying to passivate or activate the node at the same time. However, we can switch to use BaseCacheLoaderInterceptor.obtainLoaderLock() to obtain locks. The same strategy used in CacheStoreInterceptor and CacheLoaderInterceptor. Please open a JIRA Issue for it and it'll be done. ) Assignee: Manik Surtani (was: Hany Mesha) Complexity: Low > Remove synchronization in Passivation/Activation interceptor > ------------------------------------------------------------ > > Key: JBCACHE-533 > URL: http://jira.jboss.com/jira/browse/JBCACHE-533 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > > This is now handled in the cache loader implementation -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-533) Remove synchronization in Passivation/Activation interceptor

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-533?page=all ] Manik Surtani closed JBCACHE-533. --------------------------------- Resolution: Done > Remove synchronization in Passivation/Activation interceptor > ------------------------------------------------------------ > > Key: JBCACHE-533 > URL: http://jira.jboss.com/jira/browse/JBCACHE-533 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > Assigned To: Manik Surtani > Fix For: 2.0.0.GA > > > This is now handled in the cache loader implementation -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCACHE-533) Change synchronization to use locks in Passivation/Activation interceptor

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-533?page=comments#action_12368879 ] Manik Surtani commented on JBCACHE-533: --------------------------------------- Synchronization removed. This is now handled in the cache loader implementations. > Change synchronization to use locks in Passivation/Activation interceptor > ------------------------------------------------------------------------- > > Key: JBCACHE-533 > URL: http://jira.jboss.com/jira/browse/JBCACHE-533 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > Assigned To: Hany Mesha > Fix For: 2.0.0.GA > > > Re synchronization in PassivationInterceptor and ActivationInterceptor > The synchronization statement is needed to prevent multiple threads from trying to passivate or activate the node at the same time. However, we can switch to use BaseCacheLoaderInterceptor.obtainLoaderLock() to obtain locks. The same strategy used in CacheStoreInterceptor and CacheLoaderInterceptor. Please open a JIRA Issue for it and it'll be done. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCACHE-371) Create Spring clustering pagakage using JBossCache

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-371?page=all ] Manik Surtani updated JBCACHE-371: ---------------------------------- Fix Version/s: 2.1.0.GA (was: 2.0.0.GA) > Create Spring clustering pagakage using JBossCache > -------------------------------------------------- > > Key: JBCACHE-371 > URL: http://jira.jboss.com/jira/browse/JBCACHE-371 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.1.0.GA > > > I don't have detailed of Spring framework, but when JBossCache 1.3 is released (with support of JDK5.0 annotation for POJO Cache), it should be able to support annotation based POJO clustering (or more accurately, state replicatiom) that can run inside Spring. If there is a contributor that is willing to take this task, please let me know. -- 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

17 years, 2 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 July 2007