May 2009 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-78) Large object support

by Manik Surtani (JIRA)

Large object support -------------------- Key: ISPN-78 URL: https://jira.jboss.org/jira/browse/ISPN-78 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.GA if each VM is allocated a 2GB heap and you have a 100 nodes in a grid with 1 redundant copy for each key, you have a theoretical addressable heap of 100GB. But you are limited by (half) the heap of a single VM per entry, since entries are stored whole. E.g., cache.put(k, my2GBObject) will fail since you need at least 2GB for the object + another 2GB for its serialized form. This gets worse when you try cache.put(k, my10GBObject). This *should* be possible if we have a theoretical 100GB heap. Potential solutions here are to fragment large objects, and store each fragment under separate keys. Another approach would be to directly stream objects to disk. etc. Needs thought and design, possibly a separate API to prevent 'pollution" of the more simplistic API. (JumboCache?) Re: fragmenting, issues to overcome: How many chunks to fragment into? Max size of each key could be configured, but how do we determine the size of an Object? VM instrumentation? Or perhaps the JumboCache only stores byte[]'s? -- 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

12 years, 3 months

10
32
0 / 0

[JBoss JIRA] Created: (ISPN-83) Remove dependency on JGroups FLUSH

by Manik Surtani (JIRA)

Remove dependency on JGroups FLUSH ---------------------------------- Key: ISPN-83 URL: https://jira.jboss.org/jira/browse/ISPN-83 Project: Infinispan Issue Type: Task Affects Versions: 4.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA FLUSH is needed to control messages not being sent when a new view is installed, as we have observed that without this, messages get dropped by the joiner. We need to find a better way to deal with this as FLUSH is expensive and not very scalable. -- 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

13 years, 6 months

4
28
0 / 0

[JBoss JIRA] Created: (ISPN-85) Investigate more efficient version marshalling

by Galder Zamarreño (JIRA)

Investigate more efficient version marshalling ---------------------------------------------- Key: ISPN-85 URL: https://jira.jboss.org/jira/browse/ISPN-85 Project: Infinispan Issue Type: Task Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.0.0.BETA1 Investigate the possibiltiy of moving VAM versioning writing to start/finish Marshaller operations and change RPC code and cache store code so that they follow the start/objectToObjectStream/finish pattern when writing and start/objectFromObjectStream/finish when reading. -- 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, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-81) Moving VAM versioning to startObjectOutput and investigate cache store marshaller usage

by Galder Zamarreño (JIRA)

Moving VAM versioning to startObjectOutput and investigate cache store marshaller usage --------------------------------------------------------------------------------------- Key: ISPN-81 URL: https://jira.jboss.org/jira/browse/ISPN-81 Project: Infinispan Issue Type: Task Components: RPC Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 4.0.0.BETA1 Promote use of start/objectToObjectStream/finish rather than having multiple objectToObjectStream() calls, specially in cache stores. By promoting this use, we can move versioning in VAM from objectToObjectStream() to start and hence serialize less data. Finally, make a note on the marshaller javadoc so that users know how to use it efficiently in future. -- 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, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-79) MarshalledValue.serialize/deserialize should be using Marshaller, not JDK classes

by Galder Zamarreño (JIRA)

MarshalledValue.serialize/deserialize should be using Marshaller, not JDK classes --------------------------------------------------------------------------------- Key: ISPN-79 URL: https://jira.jboss.org/jira/browse/ISPN-79 Project: Infinispan Issue Type: Task Affects Versions: 4.0.0.ALPHA3 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.0.0.BETA1 -- 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, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-80) Bucket marshalling with MarshallerImpl appears to be broken

by Galder Zamarreño (JIRA)

Bucket marshalling with MarshallerImpl appears to be broken ----------------------------------------------------------- Key: ISPN-80 URL: https://jira.jboss.org/jira/browse/ISPN-80 Project: Infinispan Issue Type: Bug Components: RPC Affects Versions: 4.0.0.ALPHA3 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.0.0.BETA1 >From MarshallersTest: java.io.IOException: Unknown magic number 0 at org.infinispan.marshall.MarshallerImpl.unmarshallObject(MarshallerImpl.java:545) at org.infinispan.marshall.MarshallerImpl.unmarshallInternalCacheEntry(MarshallerImpl.java:581) at org.infinispan.marshall.MarshallerImpl.unmarshallObject(MarshallerImpl.java:475) at org.infinispan.marshall.MarshallerImpl.unmarshallBucket(MarshallerImpl.java:561) at org.infinispan.marshall.MarshallerImpl.unmarshallObject(MarshallerImpl.java:505) at org.infinispan.marshall.MarshallerImpl.unmarshallObject(MarshallerImpl.java:444) at org.infinispan.marshall.MarshallerImpl.objectFromObjectStream(MarshallerImpl.java:964) at org.infinispan.marshall.MarshallerImpl.objectFromByteBuffer(MarshallerImpl.java:982) at org.infinispan.marshall.MarshallerImpl.objectFromByteBuffer(MarshallerImpl.java:986) at org.infinispan.marshall.MarshallersTest.testBucketMarshalling(MarshallersTest.java:377) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580) at org.testng.internal.Invoker.invokeMethod(Invoker.java:478) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:617) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:885) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:126) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:110) at org.testng.TestRunner.runWorkers(TestRunner.java:712) at org.testng.TestRunner.privateRun(TestRunner.java:582) at org.testng.TestRunner.run(TestRunner.java:477) at org.testng.SuiteRunner.runTest(SuiteRunner.java:324) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:319) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:292) at org.testng.SuiteRunner.run(SuiteRunner.java:198) at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:823) at org.testng.TestNG.runSuitesLocally(TestNG.java:790) at org.testng.TestNG.run(TestNG.java:708) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:124) Remember that MarshallersTest verifies number of bytes written with different marshallers and until now, it's been disabled due to JBMAR based marshaller having bigger payloads, but this could be changing soon :) -- 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
2
0 / 0

[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] Created: (ISPN-82) Expose the cache version in the CacheManager MBean

by Heiko W. Rupp (JIRA)

Expose the cache version in the CacheManager MBean -------------------------------------------------- Key: ISPN-82 URL: https://jira.jboss.org/jira/browse/ISPN-82 Project: Infinispan Issue Type: Sub-task Components: JMX and reporting Affects Versions: 4.0.0.ALPHA3 Reporter: Heiko W. Rupp Assignee: Manik Surtani The cache manager mbean should expose the version string (e.g. 'Starobrno' 4.0.0.ALPHA3 ) in a 'version' attribute. -- 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

3
5
0 / 0

[JBoss JIRA] Resolved: (ISPN-20) check whether locking is needed within JDBC cache stores

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-20?page=com.atlassian.jira.plugin... ] Mircea Markus resolved ISPN-20. ------------------------------- Resolution: Done mark as resolved for now > check whether locking is needed within JDBC cache stores > -------------------------------------------------------- > > Key: ISPN-20 > URL: https://jira.jboss.org/jira/browse/ISPN-20 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Locking and Concurrency > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > Not sure whether the 'outside' locking (MVCC) can't be used so that we won't need locking code within cache stores -- 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] Commented: (ISPN-20) check whether locking is needed within JDBC cache stores

by Mircea Markus (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-20?page=com.atlassian.jira.plugin... ] Mircea Markus commented on ISPN-20: ----------------------------------- I've just tried this approach but it fails due to the not-atomic nature of CacheStore.store operation. Store first checks that the entry is/isn't in the cache (1st interaction) and then inserts/updates it. Now following will fail 1. thread_1: calls store 2. thread_1: startLocalTx (conn.setAutocomit(false)) 3. thread_1: read_entry //entry does not exist 4. thread_2: inserts_entry 5. thread_1: inserts same entry -> failure! Now I've tried another approach in which instead of 3 I do an removeRow, just to 'force WL' on it, and then an inser directly, of course in the same local transaction. This fails as well, bot with ReadCommited and RepetableRead. And that's a bit strange, but guess there's not a total compliance for all vendors with isolation level semantics. With this in mind it might be not such a bad idea to have our own locking level and not rely on the database. Another approach would be to have a config element, something like 'forceStoreLocking' - if true then use locking, othewise rely on the database. This is a bit more complex, implementation wise. Also, we would have to test at least with the popular databases and document which databases, with which isolation levels etc can be relied on for locking... > check whether locking is needed within JDBC cache stores > -------------------------------------------------------- > > Key: ISPN-20 > URL: https://jira.jboss.org/jira/browse/ISPN-20 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Locking and Concurrency > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 4.0.0.BETA1, 4.0.0.GA > > > Not sure whether the 'outside' locking (MVCC) can't be used so that we won't need locking code within cache stores -- 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 May 2009