May 2009 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Commented: (ISPN-59) Add unit test that verifies number of written bytes

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-59?page=com.atlassian.jira.plugin... ] Galder Zamarreño commented on ISPN-59: -------------------------------------- Just talked to David online and he explained that it's not version that's in been added to each individual object, but that each object is written separated in blocks, which is what is adding extra information. It's not specific version information. This is apparently something useful for security reasons. We're discussing adding a security flag to enable/disable this. > Add unit test that verifies number of written bytes > --------------------------------------------------- > > Key: ISPN-59 > URL: https://jira.jboss.org/jira/browse/ISPN-59 > Project: Infinispan > Issue Type: Sub-task > Components: RPC > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 4.0.0.BETA1, 4.0.0.GA > > Attachments: MarshallerTest.java, org.infinispan.marshall.MarshallersTest-v2-onlyobjecttable.xml, org.infinispan.marshall.MarshallersTest-v2-onlyobjecttable_and_version=0.xml, org.infinispan.marshall.MarshallerTest.xml > > > Add written byte number comparisons to present JBossMarshallerTest to make sure that it writes > less bytes that existing MarshallerImpl and standard Java Serialization (ObjectStreamMarshaller) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-59) Add unit test that verifies number of written bytes

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-59?page=com.atlassian.jira.plugin... ] Galder Zamarreño updated ISPN-59: --------------------------------- Attachment: org.infinispan.marshall.MarshallersTest-v2-onlyobjecttable_and_version=0.xml There's even more squeezing that can be done here. If we set JBMAR version to 0, JBMAR does not add to version info to each object it actually writes. We need a version for each call to Marshaller.objectToObjectStream(), not for each individual object that a single call to objectToObjectStream marshalls. So, if we set version to 0, the number of tests failing due to JBMAR serializing less bytes than home grown drastically reduces. Only one test fails now: testSetMarshalling: JBoss Marshaller should write less bytes: bytesJBoss=64, bytesHome=58 The other tests failing are related to home grown marshalling issues (similar to ISPN-80) or the MarshalledValue issue in ISPN-79. Bottom line: JBMAR is looking better and now the payloads are almost always smaller. > Add unit test that verifies number of written bytes > --------------------------------------------------- > > Key: ISPN-59 > URL: https://jira.jboss.org/jira/browse/ISPN-59 > Project: Infinispan > Issue Type: Sub-task > Components: RPC > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 4.0.0.BETA1, 4.0.0.GA > > Attachments: MarshallerTest.java, org.infinispan.marshall.MarshallersTest-v2-onlyobjecttable.xml, org.infinispan.marshall.MarshallersTest-v2-onlyobjecttable_and_version=0.xml, org.infinispan.marshall.MarshallerTest.xml > > > Add written byte number comparisons to present JBossMarshallerTest to make sure that it writes > less bytes that existing MarshallerImpl and standard Java Serialization (ObjectStreamMarshaller) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-59) Add unit test that verifies number of written bytes

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-59?page=com.atlassian.jira.plugin... ] Galder Zamarreño updated ISPN-59: --------------------------------- Attachment: org.infinispan.marshall.MarshallersTest-v2-onlyobjecttable.xml Attaching v2 after implementing ObjectTable based solution. This drastically reduces the sizes of payload. Examples: testListMarshalling 472(v1) -> 393(v2) (vs 334 with MarshallerImpl) testImmutableResponseMarshalling - passed :) testSingletonListMarshalling 100(v1) -> 77(v2) (vs 72 with MarshallerImpl) testInternalCacheEntryMarshalling 36(v1) -> 26(v2) (vs 25 with MarshallerImpl) testSetMarshalling 76(v1) -> 68(v2) (vs 58 with MarshallerImpl) ...etc More to come... Note that the failures in testBucketMarshalling and testMarshalledValueMarshalling are due to ISPN79 and ISPN-80. > Add unit test that verifies number of written bytes > --------------------------------------------------- > > Key: ISPN-59 > URL: https://jira.jboss.org/jira/browse/ISPN-59 > Project: Infinispan > Issue Type: Sub-task > Components: RPC > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 4.0.0.BETA1, 4.0.0.GA > > Attachments: MarshallerTest.java, org.infinispan.marshall.MarshallersTest-v2-onlyobjecttable.xml, org.infinispan.marshall.MarshallerTest.xml > > > Add written byte number comparisons to present JBossMarshallerTest to make sure that it writes > less bytes that existing MarshallerImpl and standard Java Serialization (ObjectStreamMarshaller) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-6) Infinispan cache provider for Hibernate

by Chris Bredesen (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-6?page=com.atlassian.jira.plugin.... ] Chris Bredesen commented on ISPN-6: ----------------------------------- I've done some work on this and I'll continue to do so. Will hit the dev list with questions. So far so good but I haven't actually turned the key yet ;) > Infinispan cache provider for Hibernate > --------------------------------------- > > Key: ISPN-6 > URL: https://jira.jboss.org/jira/browse/ISPN-6 > Project: Infinispan > Issue Type: Feature Request > Reporter: Manik Surtani > Assignee: Chris Bredesen > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > Hibernate will need a cache provider plugin for Hibernate. While this will reside in the Hibernate trunk codebase, the JIRA is tracked here. > General ideas: > Use a separate named cache per entity. This cache would hold entity instances as well as collections pertaining to that entity. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (ISPN-6) Infinispan cache provider for Hibernate

by Chris Bredesen (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-6?page=com.atlassian.jira.plugin.... ] Chris Bredesen reassigned ISPN-6: --------------------------------- Assignee: Chris Bredesen (was: Manik Surtani) > Infinispan cache provider for Hibernate > --------------------------------------- > > Key: ISPN-6 > URL: https://jira.jboss.org/jira/browse/ISPN-6 > Project: Infinispan > Issue Type: Feature Request > Reporter: Manik Surtani > Assignee: Chris Bredesen > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > Hibernate will need a cache provider plugin for Hibernate. While this will reside in the Hibernate trunk codebase, the JIRA is tracked here. > General ideas: > Use a separate named cache per entity. This cache would hold entity instances as well as collections pertaining to that entity. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (ISPN-54) Create migration script for JBoss Cache 3.1

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-54?page=com.atlassian.jira.plugin... ] Mircea Markus resolved ISPN-54. ------------------------------- Resolution: Done > Create migration script for JBoss Cache 3.1 > ------------------------------------------- > > Key: ISPN-54 > URL: https://jira.jboss.org/jira/browse/ISPN-54 > Project: Infinispan > Issue Type: Sub-task > Components: Configuration, Migration tools > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 4.0.0.BETA1, 4.0.0.GA > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (ISPN-53) Create migration script for JBoss Cache 3.0

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-53?page=com.atlassian.jira.plugin... ] Mircea Markus resolved ISPN-53. ------------------------------- Resolution: Done org.infinispan.config.parsing.ConfigFilesConvertor was created, together with scripts for running it > Create migration script for JBoss Cache 3.0 > ------------------------------------------- > > Key: ISPN-53 > URL: https://jira.jboss.org/jira/browse/ISPN-53 > Project: Infinispan > Issue Type: Sub-task > Components: Configuration, Migration tools > Reporter: Manik Surtani > Assignee: Mircea Markus > Fix For: 4.0.0.BETA1, 4.0.0.GA > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Resolved: (ISPN-48) Introduce lock() and unlock() API methods

by Vladimir Blagojevic (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-48?page=com.atlassian.jira.plugin... ] Vladimir Blagojevic resolved ISPN-48. ------------------------------------- Resolution: Done > Introduce lock() and unlock() API methods > ----------------------------------------- > > Key: ISPN-48 > URL: https://jira.jboss.org/jira/browse/ISPN-48 > Project: Infinispan > Issue Type: Feature Request > Components: Locking and Concurrency > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > This would be the fabled distributed locking. > These APIs should be on AdvancedCache, with the following sigs: > void lock(K key, boolean eager); > void lock(Collection<? extends K> keys, boolean eager); > void unlock(K key); > void unlock(Collection<? extends K> keys); > The implementation should use a new Command, a LockControlCommand, which contains: > * a boolean to indicate whether this is a lock or unlock > * a boolean to indicate whether this is an eager lock > * an array of keys to be locked/unlocked > The command is handled by the LockingInterceptor which will acquire/release locks as needed. > If eager, the ReplicationInterceptor will replicate this command *synchronously* (even if repl mode is async) to ensure all remote nodes have locked/unlocked as well. (should this sync force only be on lock() and not unlock()?) If using DIST, this would only be replicated among peers where the relevant keys are mapped. > On a transaction prepare, lock()s that are NOT eager should also be respected and applied. > On transaction rollback, locks should be unlocked as usual, so unlock() commands need not be a part of the prepare. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-48) Introduce lock() and unlock() API methods

by Vladimir Blagojevic (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-48?page=com.atlassian.jira.plugin... ] Vladimir Blagojevic commented on ISPN-48: ----------------------------------------- Related unit test is SyncReplLockingTest > Introduce lock() and unlock() API methods > ----------------------------------------- > > Key: ISPN-48 > URL: https://jira.jboss.org/jira/browse/ISPN-48 > Project: Infinispan > Issue Type: Feature Request > Components: Locking and Concurrency > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > This would be the fabled distributed locking. > These APIs should be on AdvancedCache, with the following sigs: > void lock(K key, boolean eager); > void lock(Collection<? extends K> keys, boolean eager); > void unlock(K key); > void unlock(Collection<? extends K> keys); > The implementation should use a new Command, a LockControlCommand, which contains: > * a boolean to indicate whether this is a lock or unlock > * a boolean to indicate whether this is an eager lock > * an array of keys to be locked/unlocked > The command is handled by the LockingInterceptor which will acquire/release locks as needed. > If eager, the ReplicationInterceptor will replicate this command *synchronously* (even if repl mode is async) to ensure all remote nodes have locked/unlocked as well. (should this sync force only be on lock() and not unlock()?) If using DIST, this would only be replicated among peers where the relevant keys are mapped. > On a transaction prepare, lock()s that are NOT eager should also be respected and applied. > On transaction rollback, locks should be unlocked as usual, so unlock() commands need not be a part of the prepare. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-48) Introduce lock() and unlock() API methods

by Vladimir Blagojevic (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-48?page=com.atlassian.jira.plugin... ] Vladimir Blagojevic commented on ISPN-48: ----------------------------------------- We decided to remove unlock call since semantics could be misused. E.g: lock(k1); int count = get(k1) put(k2, count); unlock(k1); commit; // Count might have changed! We also decided to allow locking within transactional context only. > Introduce lock() and unlock() API methods > ----------------------------------------- > > Key: ISPN-48 > URL: https://jira.jboss.org/jira/browse/ISPN-48 > Project: Infinispan > Issue Type: Feature Request > Components: Locking and Concurrency > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > This would be the fabled distributed locking. > These APIs should be on AdvancedCache, with the following sigs: > void lock(K key, boolean eager); > void lock(Collection<? extends K> keys, boolean eager); > void unlock(K key); > void unlock(Collection<? extends K> keys); > The implementation should use a new Command, a LockControlCommand, which contains: > * a boolean to indicate whether this is a lock or unlock > * a boolean to indicate whether this is an eager lock > * an array of keys to be locked/unlocked > The command is handled by the LockingInterceptor which will acquire/release locks as needed. > If eager, the ReplicationInterceptor will replicate this command *synchronously* (even if repl mode is async) to ensure all remote nodes have locked/unlocked as well. (should this sync force only be on lock() and not unlock()?) If using DIST, this would only be replicated among peers where the relevant keys are mapped. > On a transaction prepare, lock()s that are NOT eager should also be respected and applied. > On transaction rollback, locks should be unlocked as usual, so unlock() commands need not be a part of the prepare. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2009