May 2009 - infinispan-issues - Jboss List Archives

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

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-49?page=com.atlassian.jira.plugin... ] Galder Zamarreño commented on ISPN-49: -------------------------------------- So, the pick up I saw with 8 nodes, I believe could be linked to these errors that made request return faster. > 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.BETA1, 4.0.0.GA > > Attachments: round-lab-0.zip, round-lab-1.zip, run1.zip, run2.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] Commented: (ISPN-49) Perf test using JBoss Marshalling marshaller layer

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-49?page=com.atlassian.jira.plugin... ] Galder Zamarreño commented on ISPN-49: -------------------------------------- In run1, with 8 nodes, I started to get loads of view changes and NAKACK errors. I suspected these could be due to garbage collection, so executed run2 with tweaked GC settings. More specifically, I used CMS garbage collection which based on previous experience in support, works very well avoiding false suspicions. > 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.BETA1, 4.0.0.GA > > Attachments: round-lab-0.zip, round-lab-1.zip, run1.zip, run2.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] Commented: (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 commented on ISPN-49: ----------------------------------- Hmm, still a little haywire to me - a lot of ups and downs. Any idea why in run1 the homegrown marshaller starts to overtake JBMAR? > 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.BETA1, 4.0.0.GA > > Attachments: round-lab-0.zip, round-lab-1.zip, run1.zip, run2.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-49) Perf test using JBoss Marshalling marshaller layer

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-49?page=com.atlassian.jira.plugin... ] Galder Zamarreño updated ISPN-49: --------------------------------- Attachment: run1.zip run2.zip Note that overall performance looks better in run2 due to tweaking VM settings. > 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.BETA1, 4.0.0.GA > > Attachments: round-lab-0.zip, round-lab-1.zip, run1.zip, run2.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] Commented: (ISPN-49) Perf test using JBoss Marshalling marshaller layer

by Galder Zamarreño (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-49?page=com.atlassian.jira.plugin... ] Galder Zamarreño commented on ISPN-49: -------------------------------------- After fixing some issues with cluster test set ups, the JBMAR performance is already better than home grown marshalling layer. See attached cluster test graphs. A couple more perf improvements will still be implemented. > 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.BETA1, 4.0.0.GA > > Attachments: round-lab-0.zip, round-lab-1.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-72) Asynchronous Cache API

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-72?page=com.atlassian.jira.plugin... ] Manik Surtani resolved ISPN-72. ------------------------------- Fix Version/s: 4.0.0.ALPHA3 (was: 4.0.0.BETA1) Resolution: Done > Asynchronous Cache API > ---------------------- > > Key: ISPN-72 > URL: https://jira.jboss.org/jira/browse/ISPN-72 > Project: Infinispan > Issue Type: Feature Request > Components: Core API, RPC > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 4.0.0.ALPHA3, 4.0.0.GA > > > Unscheduled for now. > From Tim Fox: > E.g. imagine I set a value in the cache, by the time I get the response that the value has been set in the cache, I also need to know that it's been replicated to another node so I can have the redundancy guarantees for high availability. > One way to do that is just to block the thread that calls set() until the replication has been performed synchronously to the other node and returns, however that will involve a network round trip per set. > What would be nice would to be able to get the acknowledgements of replication back asynchronously in a different stream, e.g. > S = Set in cache, A = acknowledgement of replication of Set() in cache > With a blocking approach you'd have > S1 > A1 > S2 > A2 > S3 > A3 > I.e. you wait for the ack of the set before calling the next set, which involves a network RTT per set. > With a non blocking (pipelined) approach, you call your sets in quick succession without waiting for a response, then some time later you'd get your ack back. > E.g. chronologically something like: > S1 > S2 > S3 > S4 > S5 > S6 > S7 > A1 > A2 > S8 > A3 > S9 > A4 > S10 > S11 > A5 > Since you're not blocking, you can use the throughput of the network without being limited by its latency. > This is the kind of thing we in messaging replication, i.e. when someone sends a load of message one by one we can't individually do a network RTT per message (it would be too slow) to replicate them, but they still need the guarantee the message has reached the backup before they get the acknolwedgement of send back. > Manik: > Returning a Future would probably be the way to do this, but I would need to think about what the API would look like though, since the API should look and behave the same regardless of cache mode/cluster config used. -- 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-20) check whether locking is needed within JDBC cache stores

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-20?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-20: ------------------------------ Summary: check whether locking is needed within JDBC cache stores (was: check whether locking is needed within cache stores) Complexity: Medium (was: High) > 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] Updated: (ISPN-69) NullPointerException when enabling TRACE

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-69?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-69: ------------------------------ Fix Version/s: 4.0.0.ALPHA3 (was: 4.0.0.BETA1) > NullPointerException when enabling TRACE > ---------------------------------------- > > Key: ISPN-69 > URL: https://jira.jboss.org/jira/browse/ISPN-69 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 4.0.0.ALPHA2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 4.0.0.ALPHA3 > > > Enabling TRACE on infinispan throws the following exception on startup: > 23:08:01,417 ERROR [CacheException] Unable to Initialize or Setup the Cache: org.cachebench.cachewrappers.InfinispanWrapper > java.lang.NullPointerException > at org.infinispan.CacheDelegate.toString(CacheDelegate.java:384) > at java.lang.String.valueOf(String.java:2827) > at java.lang.StringBuilder.append(StringBuilder.java:115) > at org.infinispan.factories.AbstractComponentRegistry$Component.toString(AbstractComponentRegistry.java:815) > at java.lang.String.valueOf(String.java:2827) > at org.infinispan.logging.AbstractLogImpl.substitute(AbstractLogImpl.java:65) > at org.infinispan.logging.AbstractLogImpl.trace(AbstractLogImpl.java:10) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:200) > at org.infinispan.factories.ComponentRegistry.registerComponent(ComponentRegistry.java:117) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:172) > at org.infinispan.factories.DefaultCacheFactory.bootstrap(DefaultCacheFactory.java:89) > at org.infinispan.factories.DefaultCacheFactory.createAndWire(DefaultCacheFactory.java:76) > at org.infinispan.factories.DefaultCacheFactory.createCache(DefaultCacheFactory.java:57) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:338) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:305) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:283) > at org.cachebench.cachewrappers.InfinispanWrapper.setUp(InfinispanWrapper.java:32) > at org.cachebench.cachewrappers.InfinispanWrapper.init(InfinispanWrapper.java:23) > at org.cachebench.CacheBenchmarkRunner.newCache(CacheBenchmarkRunner.java:141) > at org.cachebench.CacheBenchmarkRunner.runTests(CacheBenchmarkRunner.java:160) > at org.cachebench.CacheBenchmarkRunner.<init>(CacheBenchmarkRunner.java:113) > at org.cachebench.CacheBenchmarkRunner.<init>(CacheBenchmarkRunner.java:92) > at org.cachebench.CacheBenchmarkRunner.main(CacheBenchmarkRunner.java:64) > Every time I'm meant to go and run the benchmark tests, I go and find something! :) -- 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-75) Support for JDBM

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-75?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-75: ------------------------------ Fix Version/s: 4.0.0.ALPHA3 (was: 4.0.0.BETA1) > Support for JDBM > ---------------- > > Key: ISPN-75 > URL: https://jira.jboss.org/jira/browse/ISPN-75 > Project: Infinispan > Issue Type: Patch > Reporter: Elias Ross > Assignee: Elias Ross > Fix For: 4.0.0.ALPHA3, 4.0.0.GA > > Attachments: jdbm.diff > > > Patch contains support for JDBM. > Uses the Apache LDAP project version of JDBM. > Needs to be reviewed. In particular, the expiration behavior. > The expiration "purging" is fairly efficient, and perhaps moreso than other cache loader/store implementations. -- 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-73) Fix NotSerializableException with InvalidateL1Command

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-73?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-73: ------------------------------ Fix Version/s: 4.0.0.ALPHA3 (was: 4.0.0.BETA1) > Fix NotSerializableException with InvalidateL1Command > ----------------------------------------------------- > > Key: ISPN-73 > URL: https://jira.jboss.org/jira/browse/ISPN-73 > Project: Infinispan > Issue Type: Bug > Components: RPC > Affects Versions: 4.0.0.ALPHA2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 4.0.0.ALPHA3 > > > Fix the following exceptions arising from using JBoss Marshalling: > Caused by: java.io.NotSerializableException: org.infinispan.commands.write.InvalidateL1Command -- 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