January 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-556) house keeping of stale prepared transactions

by Mircea Markus (JIRA)

house keeping of stale prepared transactions -------------------------------------------- Key: ISPN-556 URL: https://jira.jboss.org/browse/ISPN-556 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 5.1.0.Final We will need a background cleanup thread to clean up stale prepares and ongoing txs that have exceeded a timeout (in cases where there is no backend TM and hence no recovery) - Timeout could be set by user (cfg) - Or by TM (XAResource.setTimeout()) Should also be able to release locks in this case -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

6
12
0 / 0

[JBoss JIRA] (ISPN-1820) SearchMapping is not recognized

by Michael Wittig (JIRA)

Michael Wittig created ISPN-1820: ------------------------------------ Summary: SearchMapping is not recognized Key: ISPN-1820 URL: https://issues.jboss.org/browse/ISPN-1820 Project: Infinispan Issue Type: Bug Components: Querying Affects Versions: 5.1.0.FINAL Environment: Windows XP, Java 1.6.0_26 Reporter: Michael Wittig Assignee: Sanne Grinovero SearchMapping is not recognized by Infinispan and therfore it is not possible to add Objects to cache where you can not add Annotations. (maybe you just have the class Files) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
8
0 / 0

[JBoss JIRA] (ISPN-1815) Reuse Marshaller and Unmarshaller instances

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-1815: ------------------------------------- Summary: Reuse Marshaller and Unmarshaller instances Key: ISPN-1815 URL: https://issues.jboss.org/browse/ISPN-1815 Project: Infinispan Issue Type: Enhancement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.1.1.CR1, 5.1.1.FINAL, 5.2.0.ALPHA1, 5.2.0.FINAL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
4
0 / 0

[JBoss JIRA] (ISPN-1809) Some online 5.1 javadoc files empty

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1809: -------------------------------------- Summary: Some online 5.1 javadoc files empty Key: ISPN-1809 URL: https://issues.jboss.org/browse/ISPN-1809 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.0.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.1.CR1, 5.1.1.FINAL Something weird's happened with the release and some javadoc files: {cpde}[g@z:~/Go/upstream/infinispan-5.1.0.FINAL]% (master) fndany AtomicMap.html | xargs ls -al -rw-r--r-- 1 g staff 0 Jan 24 22:30 ./target/distribution/infinispan-5.1.0.FINAL/doc/5.1/apidocs/org/infinispan/atomic/AtomicMap.html ... -rw-r--r-- 1 g staff 16784 Jan 24 22:28 ./target/site/apidocs/org/infinispan/atomic/AtomicMap.html{code} The generate javadoc file is fine, but the one that was extracted from the distro zip file is not. Same thing happens with AtomicHashMapProxy.html Upload the correct files. Dunno what could have caused this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
5
0 / 0

[JBoss JIRA] (ISPN-1816) Problem with Infinispan 5.1.0.FINAL and put with lifespan parameter

by Damiano Pezzotti (JIRA)

Damiano Pezzotti created ISPN-1816: -------------------------------------- Summary: Problem with Infinispan 5.1.0.FINAL and put with lifespan parameter Key: ISPN-1816 URL: https://issues.jboss.org/browse/ISPN-1816 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.FINAL Reporter: Damiano Pezzotti Assignee: Manik Surtani Priority: Blocker Fix For: 5.1.1.CR1, 5.1.1.FINAL Hi, I'm trying to migrate my application to Infinispan 5.1.0.FINAL but I have some problem. My code uses put method passing lifespan parameter. In the new Infinispan version it seems that if I put an entry to the cache with a lifespan (e.g. 10 seconds) and then, after 5 seconds, I put the same entry with lifespan = 10 seconds, the lifespan is not overrided and the cache entry expires after 10 seconds from the first operation. Here an example of code that reproduces the problem: final Cache cache = .... // Obtain cache instance // Put entry in cache cache.put( "key_001", "v_001", 10, TimeUnit.SECONDS ); int x = 0; while ( true ) { // print cache entry every 500ms System.out.println( ( x++ * 500 ) + "--->" + cache.get( "key_001" ) ); // every 5 seconds put the same entry with lifespan = 10 seconds if ( x % 10 == 0 ) { System.out.println("PING"); cache.put( "key_001", "v_001", 10, TimeUnit.SECONDS ); } Thread.sleep( 500 ); } The results is: 0--->v_001 500--->v_001 1000--->v_001 1500--->v_001 2000--->v_001 2500--->v_001 3000--->v_001 3500--->v_001 4000--->v_001 4500--->v_001 PING 5000--->v_001 5500--->v_001 6000--->v_001 6500--->v_001 7000--->v_001 7500--->v_001 8000--->v_001 8500--->v_001 9000--->v_001 9500--->v_001 PING 10000--->null 10500--->null 11000--->null 11500--->null 12000--->null 12500--->null 13000--->null 13500--->null 14000--->null 14500--->null PING 15000--->v_001 15500--->v_001 16000--->v_001 16500--->v_001 17000--->v_001 17500--->v_001 With Infinispan 5.0.1 the result is 0--->v_001 500--->v_001 1000--->v_001 1500--->v_001 2000--->v_001 2500--->v_001 3000--->v_001 3500--->v_001 4000--->v_001 4500--->v_001 PING 5000--->v_001 5500--->v_001 6000--->v_001 6500--->v_001 7000--->v_001 7500--->v_001 8000--->v_001 8500--->v_001 9000--->v_001 9500--->v_001 PING 10000--->v_001 10500--->v_001 11000--->v_001 11500--->v_001 12000--->v_001 12500--->v_001 13000--->v_001 13500--->v_001 14000--->v_001 14500--->v_001 PING 15000--->v_001 15500--->v_001 16000--->v_001 16500--->v_001 17000--->v_001 17500--->v_001 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
9
0 / 0

[JBoss JIRA] (ISPN-20) check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-20?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño reassigned ISPN-20: ------------------------------------ Assignee: Tristan Tarrant (was: Galder Zamarreño) > check whether locking in JDBC cache stores can be replaced with SELECT FOR UPDATE > --------------------------------------------------------------------------------- > > Key: ISPN-20 > URL: https://issues.jboss.org/browse/ISPN-20 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Locking and Concurrency > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Labels: hackathon > Fix For: 5.2.0.FINAL > > > 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, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-701) Redesign TableManipulation in JDBC cache loader

by Trustin Lee (JIRA)

Redesign TableManipulation in JDBC cache loader ----------------------------------------------- Key: ISPN-701 URL: https://jira.jboss.org/browse/ISPN-701 Project: Infinispan Issue Type: Task Components: Loaders and Stores Reporter: Trustin Lee Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final There are two on-going issues related with TableManipulation at the moment: ISPN-686 and ISPN-698. They both are related with vendor specific behavior, and the current implementation uses switch-cases to deal with the differences between vendors. Could we instead use inheritance to make the code look cleaner and easier to maintain? Hibernate does so: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/trunk/core/src/... Also, the properties like custom types, names, prefixes, fetch/batch sizes could be moved to AbstractJdbcCacheStoreConfig (or its subclass because we have mixed JDBC store) instead of exposing TableManipulation directly to a user. Since Hibernate already provides very well defined dialect metadata model, we could simply tap into it. However, we should wrap it with a simple wrapper class so that a user can configure the JDBC store without the knowledge of Hibernate. This is a backward incompatible change - will be done in 5.0, and TableManipulation and its related methods should be deprecated in 4.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

5
16
0 / 0

[JBoss JIRA] Created: (ISPN-484) Querying over HotRod

by Galder Zamarreno (JIRA)

Querying over HotRod -------------------- Key: ISPN-484 URL: https://jira.jboss.org/browse/ISPN-484 Project: Infinispan Issue Type: Feature Request Components: Cache Server, Querying Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.1.0.Final Investigate how to allow Hot Rod servers to be queries, particularly since server stores key/values in serialized byte arrays. Also, look into how to improve the protocol to potentially allow remote querying. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-449) Streaming over Hot Rod

by Galder Zamarreno (JIRA)

Streaming over Hot Rod ---------------------- Key: ISPN-449 URL: https://jira.jboss.org/browse/ISPN-449 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Manik Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final Extend large object support/streaming to Hot Rod -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

3
6
0 / 0

[JBoss JIRA] (ISPN-61) Dynamically switch between single and two phase commit based on cluster size

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-61?page=com.atlassian.jira.plugin.sy... ] Manik Surtani updated ISPN-61: ------------------------------ Fix Version/s: 6.0.0.FINAL (was: 5.2.0.FINAL) > Dynamically switch between single and two phase commit based on cluster size > ---------------------------------------------------------------------------- > > Key: ISPN-61 > URL: https://issues.jboss.org/browse/ISPN-61 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 4.0.0.ALPHA4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.FINAL > > > Following 2 optimizations might be implemented with respect to transactions. > 1) From an email on infinispan-dev (horizon-dev actually): > if there are only two members int the cluster always use an 1PC. If the 1st phase fails remotely, then also rollback locally. This would reduce one network roundtrip. > While this is an interesting thought, it does raise the potential for race conditions - since this decision will have to be taken in the TxInterceptor in the beforeCompletion phase of a transaction, and by the time the call gets to the interceptor for replication, the topology may have changed such that you need to replicate to 2 instead of 1 other peer. Which would mean a 2PC again. So it does need some thought. > 2) when asked to prepare, a participant might return a value indicating that no changes were made (read-only participant), so this one won't need an commit message, so less roundtrip. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 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 January 2012