February 2011 - infinispan-issues

[JBoss JIRA] Resolved: (ISPN-46) Feature comparison with other products

by Manik Surtani (JIRA)

[ https://issues.jboss.org/browse/ISPN-46?page=com.atlassian.jira.plugin.sy... ] Manik Surtani resolved ISPN-46. ------------------------------- Fix Version/s: (was: 5.0.0.Final) Resolution: Won't Fix Doesn't belong here > Feature comparison with other products > -------------------------------------- > > Key: ISPN-46 > URL: https://issues.jboss.org/browse/ISPN-46 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Manik Surtani > > Compare (feature wise) against other products: > - Coherence, Terracotta and gigaspaces, hadoop, mogileFS -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-913) Cache store modification types Prepare and Commit and related classes should be removed

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-913?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-913: ---------------------------------- Issue Type: Task (was: Bug) Rather than a bug, this is a task. > Cache store modification types Prepare and Commit and related classes should be removed > --------------------------------------------------------------------------------------- > > Key: ISPN-913 > URL: https://issues.jboss.org/browse/ISPN-913 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Sanne Grinovero > Fix For: 4.2.1.Final, 5.0.0.ALPHA3, 5.0.0.Final > > > What are the roles of Modification.Type: PREPARE, COMMIT ? These are no longer used for anything, including their correspondent org.infinispan.loaders.modifications.Prepare and org.infinispan.loaders.modifications.Commit classes. Since these are internal classes, we should get rid of them directly. > It appears that since Sanne added ModificationList as type of modification in 4.1 (ISPN-618), Prepare/Commit are no longer in use. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-913) Cache store modification types Prepare and Commit and related classes should be removed

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-913?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-913: --------------------------------------- Sanne, I've assigned this to you since you worked on the related jira? Ping me if this is any prob for you. > Cache store modification types Prepare and Commit and related classes should be removed > --------------------------------------------------------------------------------------- > > Key: ISPN-913 > URL: https://issues.jboss.org/browse/ISPN-913 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Galder Zamarreño > Assignee: Sanne Grinovero > Fix For: 4.2.1.Final, 5.0.0.ALPHA3, 5.0.0.Final > > > What are the roles of Modification.Type: PREPARE, COMMIT ? These are no longer used for anything, including their correspondent org.infinispan.loaders.modifications.Prepare and org.infinispan.loaders.modifications.Commit classes. Since these are internal classes, we should get rid of them directly. > It appears that since Sanne added ModificationList as type of modification in 4.1 (ISPN-618), Prepare/Commit are no longer in use. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-271) Expose global information in RpcManagerImpl via CacheManager

by Galder Zamarreno (JIRA)

Expose global information in RpcManagerImpl via CacheManager ------------------------------------------------------------ Key: ISPN-271 URL: https://jira.jboss.org/jira/browse/ISPN-271 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management, RPC Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 RpcManagerImpl exposes information that are both global to all caches under a cache manager and information that is specific to a cache. An idea would be to expose any global information via CacheManager mbean instead, i.e. address, cluster members And the rest, stuff that is cache specific, expose via rpc manager mbean, -- 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, 5 months

4
7
0 / 0

[JBoss JIRA] Created: (ISPN-849) testTransactional doesn't ever work

by luca stancapiano (JIRA)

testTransactional doesn't ever work ----------------------------------- Key: ISPN-849 URL: https://issues.jboss.org/browse/ISPN-849 Project: Infinispan Issue Type: Bug Environment: mac osx Reporter: luca stancapiano Assignee: Manik Surtani I'm triing testTransactional inside distribution.rehash.ConcurrentNonOverlappingLeaveTest . Often it doesn't update the c1 cache with the value "transactionally_replaced" instead of "v1". I thought about a syncronization problem of the Threads but I see that the put of the field always is executed before the get. Actually the problem seems be in org.infinispan.distribution.rehash.RehashTestBase class (95-109): TransactionManager t1 = TestingUtil.getTransactionManager(c1); t1.begin(); c1.put(keys.get(0), "transactionally_replaced"); Transaction tx = t1.getTransaction(); tx.enlistResource(new XAResourceAdapter() { public int prepare(Xid id) { // this would be called *after* the cache prepares. try { l.await(); } catch (InterruptedException e) { } return XAResource.XA_OK; } }); t1.commit(); maybe sometime there is a rollback -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
6
0 / 0

[JBoss JIRA] Updated: (ISPN-909) Segments locked during merge

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-909?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant updated ISPN-909: --------------------------------- Attachment: rabbit-2-mergelock.log rabbit-2-mergelock log > Segments locked during merge > ---------------------------- > > Key: ISPN-909 > URL: https://issues.jboss.org/browse/ISPN-909 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 4.2.0.Final > Reporter: Tristan Tarrant > Assignee: Sanne Grinovero > Attachments: rabbit-1-mergelock.log, rabbit-2-mergelock.log > > > We're getting failures on acquiring locks during merges. Here is the configuration: > Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction). > Node 1: coordinator, IndexWriter open constantly and writing a stream of documents > Node 2: opens a read-only IndexReader on-demand to perform queries (we're moving to use IndexReader.reopen() ). > Occasionally when performing queries on node 2 we get the attached stack traces. We then get corrupt indexes (java.io.IOException: Read past EOF). > We are using the default Distributed Segment Lock Reader, default 16K chunks and no tuning of the merge policies. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-909) Segments locked during merge

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-909?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant updated ISPN-909: --------------------------------- Attachment: rabbit-1-mergelock.log rabbit-1-mergelock log > Segments locked during merge > ---------------------------- > > Key: ISPN-909 > URL: https://issues.jboss.org/browse/ISPN-909 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 4.2.0.Final > Reporter: Tristan Tarrant > Assignee: Sanne Grinovero > Attachments: rabbit-1-mergelock.log, rabbit-2-mergelock.log > > > We're getting failures on acquiring locks during merges. Here is the configuration: > Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction). > Node 1: coordinator, IndexWriter open constantly and writing a stream of documents > Node 2: opens a read-only IndexReader on-demand to perform queries (we're moving to use IndexReader.reopen() ). > Occasionally when performing queries on node 2 we get the attached stack traces. We then get corrupt indexes (java.io.IOException: Read past EOF). > We are using the default Distributed Segment Lock Reader, default 16K chunks and no tuning of the merge policies. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 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 February 2011