July 2009 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-124) VAM move @Inject code into @Start

by Galder Zamarreno (JIRA)

VAM move @Inject code into @Start --------------------------------- Key: ISPN-124 URL: https://jira.jboss.org/jira/browse/ISPN-124 Project: Infinispan Issue Type: Task Components: RPC Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.BETA1 As per an email converstion, move call to JBossMarshaller.init() from an @Inject method in VAM to an @Start method. @Inject should only assign variables, do no processing. Any lengthier processing should be done at @Start. -- 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
2
0 / 0

[JBoss JIRA] Created: (ISPN-108) Remove Commons Logging dependency

by Galder Zamarreno (JIRA)

Remove Commons Logging dependency --------------------------------- Key: ISPN-108 URL: https://jira.jboss.org/jira/browse/ISPN-108 Project: Infinispan Issue Type: Thirdparty Change Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.BETA1 JGroups 2.8.Beta1 does no longer depend on Commons Logging, so we could remove such dependency from ISPN. -- 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
3
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-112) TransientMortalCacheEntry missing toString() implementation

by Galder Zamarreno (JIRA)

TransientMortalCacheEntry missing toString() implementation ----------------------------------------------------------- Key: ISPN-112 URL: https://jira.jboss.org/jira/browse/ISPN-112 Project: Infinispan Issue Type: Task Affects Versions: 4.0.0.ALPHA5 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.BETA1 Implement TransientMortalCacheEntry.toString(), otherwise debugging shows reduced information -- 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
2
0 / 0

[JBoss JIRA] Created: (ISPN-111) InternalEntryFactory mixing up lifespan and created for MortalCacheValue

by Galder Zamarreno (JIRA)

InternalEntryFactory mixing up lifespan and created for MortalCacheValue ------------------------------------------------------------------------ Key: ISPN-111 URL: https://jira.jboss.org/jira/browse/ISPN-111 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.0.0.ALPHA5 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.BETA1 For MortalCacheValue, InternalEntryFactory.createValue(Object, long, long, long , long) was doing the following: if (lifespan > -1 && maxIdle < 0) return new MortalCacheValue(v, lifespan, created); But the MortalCacheValue constructor was like this: MortalCacheValue(Object value, long created, long lifespan) { super(value); this.created = created; this.lifespan = lifespan; } So that factory method was mixing up created and lifespan values. JBMAR externalizer implementations uses this factory method and hence when testing it, the issue arised. -- 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
3
0 / 0

[JBoss JIRA] Created: (ISPN-110) FileCacheStore.fromStreamLockSafe() should only read available bytes or streamBufferSize

by Galder Zamarreno (JIRA)

FileCacheStore.fromStreamLockSafe() should only read available bytes or streamBufferSize ---------------------------------------------------------------------------------------- Key: ISPN-110 URL: https://jira.jboss.org/jira/browse/ISPN-110 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.0.0.ALPHA5 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.BETA1 With VAM, that uses JBoss Marshaller underneath, FileCacheStore.fromStreamLockSafe() should only try to read as many bytes as "int numBytes = objectInput.readInt();" returned or streamBufferSize if bigger, otherwise it will read too much. Remember that to safe payload space, JBMAR avoided adding markers at the end of each object so we should make sure only the required number of bytes are read. -- 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
3
0 / 0

[JBoss JIRA] Created: (ISPN-120) Inmortal cache entries stored as mortal entries in cache store

by Galder Zamarreno (JIRA)

Inmortal cache entries stored as mortal entries in cache store -------------------------------------------------------------- Key: ISPN-120 URL: https://jira.jboss.org/jira/browse/ISPN-120 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 4.0.0.ALPHA5 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.BETA1 Let's say you have a cluster of 3 nodes: n1, n2, and n3, you're using a shared cache sotre and and you store 1=one inmortal k,v pair in n1, Assume that the owners should be n2 and n3. There appears to be a bug in which n2 stores the inmortal entry as mortal with default lifespan for L1. This arose during demo testing. Needs further investigation. Another thing to check is purging of expired entries in cache store. When an expired entry is loaded, it's not purged from the store, maybe it should do so?? -- 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
6
0 / 0

[JBoss JIRA] Created: (ISPN-115) CacheStoreInterceptor hangs when concurrent access to txStores HashMap

by Takayoshi Kimura (JIRA)

CacheStoreInterceptor hangs when concurrent access to txStores HashMap ---------------------------------------------------------------------- Key: ISPN-115 URL: https://jira.jboss.org/jira/browse/ISPN-115 Project: Infinispan Issue Type: Bug Affects Versions: 4.0.0.ALPHA5 Reporter: Takayoshi Kimura Assignee: Manik Surtani The CacheStoreInterceptor code in this project has JBCACHE-1516 issue. -- 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] 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: ------------------------------- Re #1: See point above, ConcurrentMap alone is not sufficient for atomicity of operations for the memcached protocol for operatons like INCR, DECR, PREPEND, APPEND, and CAS. Each requires a read followed by a write, and are stated by the protocol to be atomic operations, i.e. the state of the given cache entry should not change inbetween the read and the write. If the intent is to support only a subset of the memcache protocol, i.e. get/set/delete then you'll be fine. Otherwise, you'll need to think about how to perform locking across operations which may correspond to multiple ops on your end. Re: #2. lifespans and time-to-live is not the same as the flags field that memcache specifies, which are basically meta-data for keys. #3: What are you using for logging now? The point of the slfj4-api is precisely to avoid dependency hell and forcing a given logging implementation, and unlike commons logging, it does this sanely. 'tis why I chose it, anyways. > 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-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: ----------------------------------- Just to clarify, as far as memcached is concerned the goal is to write a server module. Not a client. The server module would wrap an Infinispan Cache instance, and would be used with any other memcached client library, be it in Java, Python, etc. I know the subject of this JIRA is a little far-reaching, but in reality it should be broken down into a few different subtasks. Regarding your points above: #1 we would want to use our own locking. This is where, to a large degree, our strength lies. I haven't looked at the memcached proto in detail yet, but if it supports atomic calls then thats what the client should use, and delegate the atomicity to the server side. Infinispan's Cache extends ConcurrentMap so you should have all you need here. #2 Infinispan's Cache supports lifespans, ttls, etc in its API. As long as this is a part of the protocol it can be translated easily enough. #4 We just want flexibility. Either way the transport needs to be pluggable so we can use XNIO/Netty/MINA/your homerolled JNI comms module using libaio/JDK7 NIO2/whatever. Picking XNIO to start with since we are familiar with it and it too is a JBoss project, other transports may evolve as and when. #6 Yes I know - it was written as a demo. It cannot be the basis of a full impl. #8 Nothing. Just that the last thing I want is to yank in yet another unnecessary dependency. > 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2009