July 2009 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Commented: (ISPN-29) Cache server and client module

by Ryan Daum (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-29?page=com.atlassian.jira.plugin... ] Ryan Daum commented on ISPN-29: ------------------------------- * remember jmemcached is still pre 1.0, and is under active development, so nothing is written in stone. * I inherited the code base from another author, though it has changed radically since then. Many things about the design that I don't like are products of that. * it's a side project for me, and I do not currently have it in any production systems at my Day Job (an earlier version was used at my previous job), so it gets less love that it could. Other people are using it. It's being used a lot for integration tests. Still, it is under active development and getting better. Re #1 (locking): The choice was made to do locking further up the call chain because I had intentions at the time of potentially introducing the ability to chain or sequence cache storages together, which would require one lock for the entire operation against all storage engines. Further I had some notions of adding transactional (commit/rollback) style semantics at the protocol level. Should I do that, I felt there would be some rather explicit locking behaviours required, and it would be better off managed by Cache. But the most important reason that Cache performs the locking is that some operations (incr, decr, cas, prepend, and append) combine reads and writes into one atomic operation. So in this case there are 3 possible options: * Re-implement all these operations for every storage engine. * Add "lock/unlock" methods to the storage engine. * Lose atomicity on these operations. If you have other suggestions, I'm open to them. In any case, maybe your storage would sit at the level of Cache (which could be made into an interface or abstract), not a CacheStorage implementation. #2 (String/MCElement storage): The protocol really dictates this. Firstly, in the protocol all keys are just strings and can't be anything else. Secondly, every element can have storage flags stored along with it, as well as its timeout. This basically requires that either the value be encapsulated in something or these attributes be external to the value. It's just easier to do the former. #3 (asynchronous deletes): This is incorrect, only delayed removes use the delayed asynchronous queue. Deletes with no delay time attached are removed instantaneously. #4 (hardcoded to netty): It took me one day to switch from MINA to Netty; so while I am not sure I truly see the advantage of using raw NIO or XNIO, it certainly is possible and if you know NIO well, it wouldn't take long. That said, I'm not sure why you would do this? Do you have benchmarks to backup your performance claims? And why would a JBoss product have a problem with a Netty dependency? One of my goals has been to get the protocol decoding/encoding abstracted out enough that I could do unit testing of it (right now there's just integration tests), but it's difficult and time consuming. #5 (license): The license is Apache 2.0, there's nothing unclear about it. Also since your comment, the main site has switched now to a google code project. #6 (jgroups impl of the protocol): Looking at the jgroups implementation of the protocol... It's not complete or correct. There's more to the protocol than sets and gets. You can reinvent the wheel and write the protocols yourself, but ... why? #7 Enum comparisons: The big if/else chain isn't sexy, but switch statement in Java is braindead. In particular, GET, GETS, and a number of others all take variations of the same logic; switch would be ungainly here. You could argue (as someone else has) that this should be a polymorphic method call per operation, but I think this would be overkill. #8 slf4j: What's wrong with slf4j? I hope you're not suggesting commons-logging... > Cache server and client module > ------------------------------ > > Key: ISPN-29 > URL: https://jira.jboss.org/jira/browse/ISPN-29 > Project: Infinispan > Issue Type: Feature Request > Components: Cache Server > Reporter: Manik Surtani > Assignee: Galder Zamarreno > Fix For: 4.1.0.BETA1, 4.1.0.GA > > > To be built on top of the cache. > Transports should be pluggable - Apache MINA, Netty, JDK7 NIO2, native, etc., but for now just build one based on XNIO > Protocols should be pluggable - memcached text-based, custom binary with server topology information > Test with various memcached clients (java and non-java) -- 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

1
0
0 / 0

[JBoss JIRA] Assigned: (ISPN-31) JPA based cache store

by Alejandro Montenegro (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-31?page=com.atlassian.jira.plugin... ] Alejandro Montenegro reassigned ISPN-31: ---------------------------------------- Assignee: Alejandro Montenegro (was: Manik Surtani) > JPA based cache store > --------------------- > > Key: ISPN-31 > URL: https://jira.jboss.org/jira/browse/ISPN-31 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Manik Surtani > Assignee: Alejandro Montenegro > Fix For: 4.1.0.BETA1, 4.1.0.GA > > > Store that uses JPA for persistence -- 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

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-29) Cache server and client module

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-29?page=com.atlassian.jira.plugin... ] Manik Surtani commented on ISPN-29: ----------------------------------- ok, thanks for the analysis. Perhaps then we can just use JMemcached for inspiration (positive and negative!). TBH I only expected to use their memcached protocol parser, but I reckon that would be trivial enough to implement ourselves given the number of strong examples we have (jmemcached, JGroups). > Cache server and client module > ------------------------------ > > Key: ISPN-29 > URL: https://jira.jboss.org/jira/browse/ISPN-29 > Project: Infinispan > Issue Type: Feature Request > Components: Cache Server > Reporter: Manik Surtani > Assignee: Galder Zamarreno > Fix For: 4.1.0.BETA1, 4.1.0.GA > > > To be built on top of the cache. > Transports should be pluggable - Apache MINA, Netty, JDK7 NIO2, native, etc., but for now just build one based on XNIO > Protocols should be pluggable - memcached text-based, custom binary with server topology information > Test with various memcached clients (java and non-java) -- 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

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-57) Support Google App Engine Sandbox

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-57?page=com.atlassian.jira.plugin... ] Manik Surtani commented on ISPN-57: ----------------------------------- Should also announce on google groups alongside http://groups.google.com/group/google-appengine-java/browse_thread/thread... > Support Google App Engine Sandbox > --------------------------------- > > Key: ISPN-57 > URL: https://jira.jboss.org/jira/browse/ISPN-57 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Reporter: Adrian Cole > Assignee: Manik Surtani > Priority: Minor > Fix For: 4.1.0.BETA1, 4.1.0.GA > > > Google App Engine for Java is a restricted JVM. It prevents such things as file access and thread creation. Currently, Infinispan requires at least thread creation and depending on the cachestore mechanism, potentially file as well. > This is a container to investigate other related issues that may prevent Infinispan from running on GAE. -- 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

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-57) Support Google App Engine

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-57?page=com.atlassian.jira.plugin... ] Manik Surtani updated ISPN-57: ------------------------------ Summary: Support Google App Engine (was: Support Google App Engine Sandbox) Priority: Major (was: Minor) > Support Google App Engine > ------------------------- > > Key: ISPN-57 > URL: https://jira.jboss.org/jira/browse/ISPN-57 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Reporter: Adrian Cole > Assignee: Manik Surtani > Fix For: 4.1.0.BETA1, 4.1.0.GA > > > Google App Engine for Java is a restricted JVM. It prevents such things as file access and thread creation. Currently, Infinispan requires at least thread creation and depending on the cachestore mechanism, potentially file as well. > This is a container to investigate other related issues that may prevent Infinispan from running on GAE. -- 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

1
0
0 / 0

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

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/ISPN-6?page=com.atlassian.jira.plugin.... ] Manik Surtani commented on ISPN-6: ---------------------------------- Chris, could you also start a wiki page (if you haven't already) detailing how to set up and use this cache provider, and link to it from http://www.jboss.org/community/wiki/Infinispan so people can find it. Probably link to it from Hibernate docs, wikis as well. > 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

15 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2009