November 2010 - infinispan-issues

[JBoss JIRA] Created: (ISPN-497) Upgrade Lucene to 2.9.3

by Sanne Grinovero (JIRA)

Upgrade Lucene to 2.9.3 ----------------------- Key: ISPN-497 URL: https://jira.jboss.org/browse/ISPN-497 Project: Infinispan Issue Type: Task Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 4.1.0.CR1, 5.0.0.BETA1 Several bugfixes made it into Lucene 2.9.3, some of which where preventing us to commit some tests as they where failing because of Lucene's erratic behaviour during commits at high load. -- 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

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-527) Implement Read-Locks for Lucene rename

by Sanne Grinovero (JIRA)

Implement Read-Locks for Lucene rename -------------------------------------- Key: ISPN-527 URL: https://jira.jboss.org/browse/ISPN-527 Project: Infinispan Issue Type: Sub-task Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.CR1, 5.0.0.BETA1 -- 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

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-526) Implement Read-Locks for Lucene delete

by Sanne Grinovero (JIRA)

Implement Read-Locks for Lucene delete -------------------------------------- Key: ISPN-526 URL: https://jira.jboss.org/browse/ISPN-526 Project: Infinispan Issue Type: Sub-task Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.CR1, 5.0.0.BETA1 -- 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

14 years, 2 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-646) Move Query Module to use Hibernate Search 3.3.0.X

by Manik Surtani (JIRA)

Move Query Module to use Hibernate Search 3.3.0.X ------------------------------------------------- Key: ISPN-646 URL: https://jira.jboss.org/browse/ISPN-646 Project: Infinispan Issue Type: Task Components: Querying Reporter: Manik Surtani Assignee: Navin Surtani Fix For: 5.0.0.BETA1, 5.0.0.Final At the time of this writing, Hibernate Search 3.3.0.Beta1 is available. Will need to test the query module accordingly after such an upgrade. https://repository.jboss.org/nexus/content/groups/public/org/hibernate/hi... -- 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

14 years, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-683) removing a Lucene segment in a single batch might run out of memory

by Sanne Grinovero (JIRA)

removing a Lucene segment in a single batch might run out of memory ------------------------------------------------------------------- Key: ISPN-683 URL: https://jira.jboss.org/browse/ISPN-683 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.0.ALPHA2, 4.1.0.Final Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.2.0.BETA1, 4.2.0.Final Apparently it can happen that the remove command of all segments chunks runs out of memory, we should avoid to use batching during this operation -- 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

14 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-670) Consider all entries from data container as eviction candidates

by Vladimir Blagojevic (JIRA)

Consider all entries from data container as eviction candidates --------------------------------------------------------------- Key: ISPN-670 URL: https://jira.jboss.org/browse/ISPN-670 Project: Infinispan Issue Type: Bug Components: Eviction Affects Versions: 4.2.0.ALPHA2, 4.1.0.Final Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic There was a subtle change of eviction semantics starting with 4.1 where only immortal entries are considered as eviction candidates. By default all entries are immortal, that is, their expiration and lifespan are -1. As soon as mortal entries are used (expiration !=-1 || lifespan !=-1) they are not subject to eviction policies and container size can grow above limit specified in maxEntries. This policy is confusing and it does not make a lot of sense. All candidates, both mortal and immortal should be considered as eviction candidates and as such subject to eviction. -- 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

14 years, 2 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-625) Lucene Directory's methods length, filemodified, touch should return 0L instead of FileNotFoundException for unexistent fils

by Sanne Grinovero (JIRA)

Lucene Directory's methods length, filemodified, touch should return 0L instead of FileNotFoundException for unexistent fils ---------------------------------------------------------------------------------------------------------------------------- Key: ISPN-625 URL: https://jira.jboss.org/browse/ISPN-625 Project: Infinispan Issue Type: Bug Affects Versions: 4.1.0.CR3 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.Final, 5.0.0.BETA1 Lucene appears to be inconsistent on this behaviour; the FSDirectory documents a FileNotfoundException but actually returns 0 while the RAMDirectory implements the FileNotfoundException but is totally synchronized, I assume the FSDirectory is more reliable in this case and we got a reported error about this, my rationale is that the race condition which FSDirectory can handle is never an issue in the synchronized blocks of RAMDirectory. Inspecting the code of Lucene, there appears to be no harm done in returning 0 for unexistend metadata. -- 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

14 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-543) Update to Scala 2.8.0.Final

by Galder Zamarreno (JIRA)

Update to Scala 2.8.0.Final --------------------------- Key: ISPN-543 URL: https://jira.jboss.org/browse/ISPN-543 Project: Infinispan Issue Type: Thirdparty Change Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR2 http://www.scala-lang.org/node/7009 -- 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

14 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-541) Revisit SLF4J dependencies in query module

by Galder Zamarreno (JIRA)

Revisit SLF4J dependencies in query module ------------------------------------------ Key: ISPN-541 URL: https://jira.jboss.org/browse/ISPN-541 Project: Infinispan Issue Type: Task Components: Querying Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 5.0.0.BETA1, 5.0.0.Final Once Hibernate Search upgrades to SLF4J 1.6, verify whether the SLF4J dependencies in the query module are still needed and check that the issue in http://community.jboss.org/wiki/InfinispanTechnicalFAQs#When_I_run_an_app... is not present any more. -- 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

14 years, 2 months

4
4
0 / 0

[JBoss JIRA] Created: (ISPN-540) Programmatically started servers should assume default host and port

by Galder Zamarreno (JIRA)

Programmatically started servers should assume default host and port -------------------------------------------------------------------- Key: ISPN-540 URL: https://jira.jboss.org/browse/ISPN-540 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR2 A Properties passed to HotRodServer or MemcachedServer needs to have host/port defined. For programmatic users, it'd be easier if they could pass an empty or null Properties object and get the servers to use default values Currently, users are forced to pass a brand new instance and set host and port. Update javadoc as well. -- 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

14 years, 2 months

2
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2010