August 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Assigned: (JBCACHE-382) JDBC persistance with pojo cache and performance issue. Slow performance after Blob inserted

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-382?page=all ] Manik Surtani reassigned JBCACHE-382: ------------------------------------- Assignee: Ben Wang (was: Hany Mesha) > JDBC persistance with pojo cache and performance issue. Slow performance after Blob inserted > -------------------------------------------------------------------------------------------- > > Key: JBCACHE-382 > URL: http://jira.jboss.com/jira/browse/JBCACHE-382 > Project: JBoss Cache > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: POJOCache > Environment: JDk 1.4.2_06, Linux Pentium 4, Debian distribution, Informix Dynamic Server 9.3 back end(running on a server elsewhere) , > Reporter: John Lukar > Assigned To: Ben Wang > Fix For: POJOCache > > Attachments: JDBC2CacheLoader.java, JDBC2CacheLoaderTest.java, testJbossCache.tar.gz > > > I turned on JDBC persistance with Informix backend using TreeCacheAOP. > The performance numbers are horribly slow. > The "jbosscache" table created as part of service startup has the columns "fqn","node","parent" with types varchar(255), blob, varchar(255) respectively. > The inserts of my pojo business objects as they are serialized into byte stream by the cache, are taking on the average of 15 seconds for each row. The DB is on another server off of the subnet. > denormolizing the pojo object and writing a row out with all pojo fields to non-blob/byte columns as varchar, integers, etc. is a lot faster. > Is this going to be the expected behaviour where JDBC persistance of POJO objects using serialized byte stream as default mechanism by TreeCache/AOP is going to be magnitude slower ? > Can someone suggest a way to use JDBC persistance and yet make it fast or as fast as file persistance, etc. ? Maybe my own cacheLoader scheme ? > I have to use JDBC/informix(vs. sleepycat) in order to not worry about local disk failure issues on persistance and recovery. A remote DB seems to be way. > thanks -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCACHE-35) Externalize the buffer queue size in LRUAlgorithm

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-35?page=all ] Manik Surtani reassigned JBCACHE-35: ------------------------------------ Assignee: Manik Surtani (was: Hany Mesha) > Externalize the buffer queue size in LRUAlgorithm > ------------------------------------------------- > > Key: JBCACHE-35 > URL: http://jira.jboss.com/jira/browse/JBCACHE-35 > Project: JBoss Cache > Issue Type: Feature Request > Affects Versions: 1.2 > Reporter: Ben Wang > Assigned To: Manik Surtani > Priority: Minor > Fix For: 2.0.0 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Currently, the LRUAlgorithm use a hard size of 5000 on the buffer queue to process node eviction. We should make this configurable so it can adapt to different enviornment. -- 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

19 years, 11 months

1
0
0 / 0

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

by Manik Surtani (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-533?page=all ] Manik Surtani reassigned JBCACHE-533: ------------------------------------- Assignee: Manik Surtani (was: Hany Mesha) > 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 > Reporter: Elias Ross > Assigned To: Manik Surtani > Fix For: 2.0.0 > > > 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-89) Externalize picking of next member for Singleton

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-89?page=all ] Brian Stansberry reassigned JBCLUSTER-89: ----------------------------------------- Assignee: Alex Fu (was: Brian Stansberry) > Externalize picking of next member for Singleton > ------------------------------------------------ > > Key: JBCLUSTER-89 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-89 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Alex Fu > Fix For: Q3Y6 > > > Currently, the HA-Singleton is always pinned to the coordinator. We should externalize the determination whom to pick, and provide a default implementation which always picks the coordinator. Thus, people can provide their own mapping from HA-Singleton to any member, as long as it is deterministic -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (JBCLUSTER-89) Externalize picking of next member for Singleton

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-89?page=all ] Brian Stansberry resolved JBCLUSTER-89. --------------------------------------- Resolution: Done > Externalize picking of next member for Singleton > ------------------------------------------------ > > Key: JBCLUSTER-89 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-89 > Project: JBoss Clustering > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Alex Fu > Fix For: Q3Y6 > > > Currently, the HA-Singleton is always pinned to the coordinator. We should externalize the determination whom to pick, and provide a default implementation which always picks the coordinator. Thus, people can provide their own mapping from HA-Singleton to any member, as long as it is deterministic -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (JBCLUSTER-25) HA JMS

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-25?page=all ] Brian Stansberry reassigned JBCLUSTER-25: ----------------------------------------- Assignee: Brian Stansberry > HA JMS > ------ > > Key: JBCLUSTER-25 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-25 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q3Y6 > > > Currently JBossMQ is using HA-Singleton for limited high availbility. There is no fail over for state, per se. > We don't have plan to enhance any HA in JBossMQ (4.0x release). > Ovidiu's new messaging system has a built-in high-availbility capability in there through the servless nature of the system. So when his new system is ready for JMS, this piece should be built in. > Remaining issues are to integrate with the current clustering framework. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBCLUSTER-17) http session replication benchmark and performance tuning

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-17?page=comments#action_12341174 ] Brian Stansberry commented on JBCLUSTER-17: ------------------------------------------- For AS 5 the main additional thing to do is benchmark buddy replication > http session replication benchmark and performance tuning > --------------------------------------------------------- > > Key: JBCLUSTER-17 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-17 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Brian Stansberry > Fix For: Q3Y6 > > > Need to benchmark http session replication using different configurations, e.g., sync mode, granularity, etc. > Also requires JBossCache to do the same first. -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-30) EJB3.0 and 2.1 clustering integration

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-30?page=all ] Brian Stansberry updated JBCLUSTER-30: -------------------------------------- Comment: was deleted > EJB3.0 and 2.1 clustering integration > ------------------------------------- > > Key: JBCLUSTER-30 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-30 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: Q3Y6 > > Original Estimate: 6 weeks > Remaining Estimate: 6 weeks > > Future ejb3.0 will run along side ejb2.1. In terms of clustering offering, ejb2.1 SFSB and entity bean will use the original implementation while 3.0 will use JBossCache and Hibernate. What's the clustering implication and integration needs? Or just pure documentation? -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-28) Create a new architecture diagram for pojo server clustering

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-28?page=all ] Brian Stansberry updated JBCLUSTER-28: -------------------------------------- Fix Version/s: Q4Y6 (was: Q3Y6) > Create a new architecture diagram for pojo server clustering > ------------------------------------------------------------ > > Key: JBCLUSTER-28 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-28 > Project: JBoss Clustering > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: Q4Y6 > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > We will need a architecture diagram for the new pojo server clustering. Since POJO server won't have http and SFSB, pure pojo clustering is in some sense like SFSB and also like entity. > But question is how to differentiate these two? How do I tag my pojo saying this is state replication and this is persistent replication? > Also, what about HA-JNDI? -- 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

19 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBCLUSTER-87) Fix netboot

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBCLUSTER-87?page=all ] Brian Stansberry updated JBCLUSTER-87: -------------------------------------- Fix Version/s: Q4Y6 (was: Q3Y6) > Fix netboot > ----------- > > Key: JBCLUSTER-87 > URL: http://jira.jboss.com/jira/browse/JBCLUSTER-87 > Project: JBoss Clustering > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assigned To: Brian Stansberry > Fix For: Q4Y6 > > > self explanatory -- 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

19 years, 11 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 August 2006