June 2009 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-84) Switch Marshalling to use JBoss Marshalling based implementation

by Galder Zamarreño (JIRA)

Switch Marshalling to use JBoss Marshalling based implementation ---------------------------------------------------------------- Key: ISPN-84 URL: https://jira.jboss.org/jira/browse/ISPN-84 Project: Infinispan Issue Type: Task Components: RPC Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.0.0.BETA1 Switch marshaller to use JBMAR based solution by default. Should be assigned to ALPHA4. -- 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

15 years, 7 months

2
3
0 / 0

[JBoss JIRA] Resolved: (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 resolved ISPN-59. ---------------------------------- Fix Version/s: 4.0.0.ALPHA4 (was: 4.0.0.BETA1) Resolution: Done > 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.ALPHA4, 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

15 years, 7 months

1
0
0 / 0

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

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-48?page=com.atlassian.jira.plugin... ] Manik Surtani reopened ISPN-48: ------------------------------- > 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.ALPHA4, 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

15 years, 7 months

1
0
0 / 0

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

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-48?page=com.atlassian.jira.plugin... ] Manik Surtani 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.ALPHA4, 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

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Resolved: (ISPN-49) Perf test using JBoss Marshalling marshaller layer

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-49?page=com.atlassian.jira.plugin... ] Manik Surtani resolved ISPN-49. ------------------------------- Fix Version/s: 4.0.0.ALPHA4 (was: 4.0.0.BETA1) Resolution: Done > Perf test using JBoss Marshalling marshaller layer > -------------------------------------------------- > > Key: ISPN-49 > URL: https://jira.jboss.org/jira/browse/ISPN-49 > Project: Infinispan > Issue Type: Task > Components: RPC > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 4.0.0.ALPHA4 > > Attachments: round-lab-0.zip, round-lab-1.zip, run1.zip, run2.zip, run3.zip, run4.zip > > > Run performance comparisons between Infinispan using home grown marshalling framework > and the one based on JBoss Marshalling. -- 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

15 years, 7 months

1
0
0 / 0

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

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-48?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-48: ------------------------------ Fix Version/s: 4.0.0.ALPHA4 (was: 4.0.0.BETA1) > 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.ALPHA4, 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

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-42) Object stream pooling

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-42?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-42: ------------------------------ Fix Version/s: 4.0.0.ALPHA4 (was: 4.0.0.BETA1) > Object stream pooling > --------------------- > > Key: ISPN-42 > URL: https://jira.jboss.org/jira/browse/ISPN-42 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Reporter: Manik Surtani > Assignee: Galder Zamarreño > Fix For: 4.0.0.ALPHA4, 4.0.0.GA > > > Make sure we pool OIS and OOS when marshalling/unmarshalling state as this is expensive to create. Consider XNIO for the necessary building blocks. -- 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

15 years, 7 months

1
0
0 / 0

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

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-53?page=com.atlassian.jira.plugin... ] Manik Surtani reopened ISPN-53: ------------------------------- > 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.ALPHA4, 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

15 years, 7 months

1
0
0 / 0

[JBoss JIRA] Reopened: (ISPN-49) Perf test using JBoss Marshalling marshaller layer

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-49?page=com.atlassian.jira.plugin... ] Manik Surtani reopened ISPN-49: ------------------------------- > Perf test using JBoss Marshalling marshaller layer > -------------------------------------------------- > > Key: ISPN-49 > URL: https://jira.jboss.org/jira/browse/ISPN-49 > Project: Infinispan > Issue Type: Task > Components: RPC > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 4.0.0.ALPHA4 > > Attachments: round-lab-0.zip, round-lab-1.zip, run1.zip, run2.zip, run3.zip, run4.zip > > > Run performance comparisons between Infinispan using home grown marshalling framework > and the one based on JBoss Marshalling. -- 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

15 years, 7 months

1
0
0 / 0

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

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-53?page=com.atlassian.jira.plugin... ] Manik Surtani resolved ISPN-53. ------------------------------- Fix Version/s: 4.0.0.ALPHA4 (was: 4.0.0.BETA1) Resolution: Done > 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.ALPHA4, 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

15 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2009