August 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-839) PojoCache to add an option to replicate final field

by Ben Wang (JIRA)

PojoCache to add an option to replicate final field --------------------------------------------------- Key: JBCACHE-839 URL: http://jira.jboss.com/jira/browse/JBCACHE-839 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0.GA We should add a flag to enable replication of final field in PojoCache. This can be done via pojocache-aop.xml, where:  <interceptor name="Start" class="org.jboss.cache.pojo.interceptors.PojoBeginInterceptor" scope="PER_INSTANCE">  <attribute name="ReplicateFinalField">true</attribute> </interceptor> -- 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

18 years, 4 months

3
6
0 / 0

[JBoss JIRA] Closed: (JBCACHE-544) Remove AbstractNode superclass

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-544?page=all ] Manik Surtani closed JBCACHE-544. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Remove AbstractNode superclass > ------------------------------ > > Key: JBCACHE-544 > URL: http://jira.jboss.com/jira/browse/JBCACHE-544 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Affects Versions: 1.3.0.GA > Reporter: Elias Ross > > If AbstractNode is not used anywhere, it's basically more code to maintain. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-508) JBossCache bechmark and performance tuning

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-508?page=all ] Manik Surtani closed JBCACHE-508. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > JBossCache bechmark and performance tuning > ------------------------------------------ > > Key: JBCACHE-508 > URL: http://jira.jboss.com/jira/browse/JBCACHE-508 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > > I have created this task specifically to document our effort in the bechmark and performance tuning process. I am using this tool that I developed to do perf test:http://jira.jboss.com/jira/browse/JBCACHE-503 > Note this load test only emulates the http session pattern now. > I will document the numbers here that I have found and discussed with Bela. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-553) JBossCache throughput II

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-553?page=all ] Manik Surtani closed JBCACHE-553. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > JBossCache throughput II > ------------------------ > > Key: JBCACHE-553 > URL: http://jira.jboss.com/jira/browse/JBCACHE-553 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Here are the results using the perf test to run our Atl clustering lab. The machines are: 2X 3.0GHZ Xeon, 4GB Ram, GBSwtich, dedicated, 140GB drive. > The load condition are: > 400 clients (total), no sleep, 7kbyte payload > async: > Cluster size, throughtput (req/sec) > 8, 1270 (8.9MB/sec) > 4, 1270 > 2, 1400 > sync: > Cluster size, throughtput (req/sec) > 8, 432 (3.0MB/sec) > 4, 480 > 2, 700 -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-478) Translate docs into Italian

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-478?page=all ] Manik Surtani closed JBCACHE-478. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Translate docs into Italian > --------------------------- > > Key: JBCACHE-478 > URL: http://jira.jboss.com/jira/browse/JBCACHE-478 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4SP1 > Reporter: Manik Surtani > Priority: Minor > > Translating JBoss Cache documentation to Italian. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-469) JGroups Channel reference to be obtained from a factory

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-469?page=all ] Manik Surtani closed JBCACHE-469. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > JGroups Channel reference to be obtained from a factory > ------------------------------------------------------- > > Key: JBCACHE-469 > URL: http://jira.jboss.com/jira/browse/JBCACHE-469 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4 > Reporter: Manik Surtani > > The JChannelFactory (will be available in JGroups 2.3 - see JGRP-112) should be used to get a channel instance. > The JChannelFactory could be obtained by: > 1) MBeanServer lookup (look up a JChannelFactoryMBean instance) > JBossCache config will need: > + JChannelFactoryMBean name > + JGroups configured stack name > JBossCache config will not need: > - Cluster name > - JGroups settings > 2) JChannelFactory instantiation > JBossCache config will need: > + Cluster name > + JGroups settings > JBossCache config will not need: > - JChannelFactoryMBean name > - JGroups configured stack name -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-432) PropertyConfigurator: investigate how to implement parsing functionality without use of PropertyEditor

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-432?page=all ] Manik Surtani closed JBCACHE-432. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > PropertyConfigurator: investigate how to implement parsing functionality without use of PropertyEditor > ------------------------------------------------------------------------------------------------------ > > Key: JBCACHE-432 > URL: http://jira.jboss.com/jira/browse/JBCACHE-432 > Project: JBoss Cache > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 1.2.3, 1.2.4beta, 1.2.4, 1.2.4SP1 > Reporter: Bela Ban > > Can you look into whether this is feasible ? If not, can you move this issue to 1.4 ? > If we could get rid of that class, we could remove jboss-common.jar -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-519) Investigate why tx has a higher thruput than non-tx under perf test

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-519?page=all ] Manik Surtani closed JBCACHE-519. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Investigate why tx has a higher thruput than non-tx under perf test > -------------------------------------------------------------------- > > Key: JBCACHE-519 > URL: http://jira.jboss.com/jira/browse/JBCACHE-519 > Project: JBoss Cache > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > > During the perf test, I have discovered that the throughput with tx is higher than the non-tx one. This is very puzzling. I have asked Scot Marlow to double check it for me. The same. > Machines are: dev09 and dev17. > Here are some breakdown numbers: > 1. Single thread, 3000 loops, 10 ms sleep interval. > (a) no tx > ----- > Total time spent (ms) per thread: 202921 for 3000 loops > Throughtput for this node with: > threads = 1 > loops = 3000 > sleep interval = 10 > object list size = 100 > tranasaction? false > is: 14 requests/sec > (b) tx > ---- > Total time spent (ms) per thread: 200718 for 3000 loops > Throughtput for this node with: > threads = 1 > loops = 3000 > sleep interval = 10 > object list size = 100 > tranasaction? true > is: 14 requests/sec > 2. 100 threads, 0ms sleep interval > (a) no tx > ----- > Total time spent (ms) per thread: 49352 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 0 > object list size = 100 > tranasaction? false > is: 404 requests/sec > ----- > Total time spent (ms) per thread: 61240 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? false > is: 325 requests/sec > -------- dev04 > Total time spent (ms) per thread: 78871 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? false > is: 250 requests/sec > (b) tx > ----- > Total time spent (ms) per thread: 68770 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 0 > object list size = 100 > tranasaction? true > is: 288 requests/sec > ---- > Total time spent (ms) per thread: 74575 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? true > is: 263 requests/sec > --- dev04 > Total time spent (ms) per thread: 80648 for 400 loops > Throughtput for this node with: > threads = 50 > loops = 400 > sleep interval = 20 > object list size = 100 > tranasaction? true > is: 242 requests/sec -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-270) Create a notification interceptor

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-270?page=all ] Manik Surtani closed JBCACHE-270. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Create a notification interceptor > --------------------------------- > > Key: JBCACHE-270 > URL: http://jira.jboss.com/jira/browse/JBCACHE-270 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4beta > Reporter: Hany Mesha > > The need has arised to create a notification interceptor to handle the callbacks results from different method call events and interceptors emitted events. -- 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

18 years, 4 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBCACHE-347) Replay tx if tx is created implicitly and fails on commit

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-347?page=all ] Manik Surtani closed JBCACHE-347. --------------------------------- Fix Version/s: (was: 2.0.0.GA) Resolution: Rejected > Replay tx if tx is created implicitly and fails on commit > --------------------------------------------------------- > > Key: JBCACHE-347 > URL: http://jira.jboss.com/jira/browse/JBCACHE-347 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 1.2.4 > Reporter: Manik Surtani > > With optimistic locking, we first check for an existing transaction, and if there isn't one, we implicitly start one. Before the method returns, if we started the tx ourselves, we make sure we commit it. > There is scope to 'replay' the tx a fixed number of times here if the commit fails. > At the moment, if the developer explicitly starts a tx before any cache operations, the cache may throw a RollbackException if it is unable to commit. If the developer doesn't explicitly start a tx, the cache may fail silently if it is unable to commit, logging errors but not throwing any exceptions. So there is scope here for silent retries without changing usage semantics. -- 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

18 years, 4 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 August 2007