July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3185) Remove license headers from source code files

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3185?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3185: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove license headers from source code files > --------------------------------------------- > > Key: ISPN-3185 > URL: https://issues.jboss.org/browse/ISPN-3185 > Project: Infinispan > Issue Type: Task > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Manik Surtani > Fix For: 6.0.0.Final, 6.0.0.Alpha1 > > > Copyright and license headers on each and every source code file is unnecessary. > A single COPYRIGHT.txt and LICENSE.txt in the project root is sufficient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3105) Design query API for both embedded use and Java Hot Rod client

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3105?page=com.atlassian.jira.plugin.... ] Mircea Markus closed ISPN-3105. ------------------------------- Resolution: Duplicate Issue Already tracked by ISPN-3105 > Design query API for both embedded use and Java Hot Rod client > -------------------------------------------------------------- > > Key: ISPN-3105 > URL: https://issues.jboss.org/browse/ISPN-3105 > Project: Infinispan > Issue Type: Task > Components: Querying > Reporter: Mircea Markus > Assignee: Adrian Nistor > Priority: Blocker > Labels: remote-query > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > There are several parts to this JIRA. > 1. We'd need a query API to be able to run queries on a cache. For example: > {code:java} > // Super-interface to Cache and RemoteCache > public interface BasicCache { > ... > Set<?> runQuery(Filter f); > ... > } > {code} > such that the same API can be used for remote (for the Hot Rod Java client) as well as embedded querying. > 2. Since the approach we're using is effectively to look at the global data set and apply a series of filters, we'd need a {{FilterBuilder}} as well to create such filters. E.g., > {code:java} > new FilterBuilder().matches("name", "QueenElizabeth").and().greaterThan("age", 65).build(); > {code} > The Hibernate Search query DSL could probably be used for inspiration. > 3. Further, we should still have an API that takes in Lucene Query objects - as per the existing Query API - but this would be for embedded mode only. E.g., > {code:java} > public interface Cache { > ... > Set<?> runLuceneQuery(LuceneQuery q); > ... > } > {code} > 4. Projections. We may also want to support projections. This needs thought. Again, Hibernate Search's APIs can provide inspiration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3332) ReadableGridFileChannel#read doesn't return -1 on EOS

by Ales Justin (JIRA)

Ales Justin created ISPN-3332: --------------------------------- Summary: ReadableGridFileChannel#read doesn't return -1 on EOS Key: ISPN-3332 URL: https://issues.jboss.org/browse/ISPN-3332 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 6.0.0.Alpha1, 5.3.0.Final Reporter: Ales Justin Assignee: Ales Justin Fix For: 5.3.1.Final, 6.0.0.Alpha2 ReadableGridFileChannel#read must return -1 on EOS. Atm it returns 0, which can cause infinite loop on read. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2903: ----------------------------------------------- Dimitris Andreadis <dandread(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] Rado, have you fixed that upstream, too? JIRA/pull requests? > Manual eviction should not delete entry from cache store > -------------------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: 5.2.x, jdg6 > Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. > It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3331) L1 should not keep data in serialised form when storeAsBinary==true

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3331: ----------------------------------- Summary: L1 should not keep data in serialised form when storeAsBinary==true Key: ISPN-3331 URL: https://issues.jboss.org/browse/ISPN-3331 Project: Infinispan Issue Type: Enhancement Reporter: Mircea Markus Assignee: William Burns Priority: Minor Raised by [~sannegrinovero] 4 years ago :-) http://lists.jboss.org/pipermail/infinispan-dev/2009-October/004371.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2903: ----------------------------------------------- Radoslav Husar <rhusar(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from ON_QA to POST > Manual eviction should not delete entry from cache store > -------------------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: 5.2.x, jdg6 > Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. > It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3330) Hotrod clients getWithMetadata doesn't work with dist/repl cache

by Jakub Markos (JIRA)

Jakub Markos created ISPN-3330: ---------------------------------- Summary: Hotrod clients getWithMetadata doesn't work with dist/repl cache Key: ISPN-3330 URL: https://issues.jboss.org/browse/ISPN-3330 Project: Infinispan Issue Type: Bug Reporter: Jakub Markos Assignee: Mircea Markus I have a cluster of 2 infinispan servers with this configuration: {code:xml}<subsystem xmlns="urn:infinispan:server:core:5.3"> <cache-container name="default" default-cache="default" listener-executor="infinispan-listener"> <transport stack="udp" executor="infinispan-transport" lock-timeout="240000"/> <distributed-cache name="default" start="EAGER" mode="SYNC" segments="1" owners="2" batching="false" l1-lifespan="0" remote-timeout="60000"> <locking isolation="REPEATABLE_READ"/> </distributed-cache> </cache-container> </subsystem>{code} Running this code: {code}remoteCache.put("k1", "v1", 10000000, TimeUnit.MICROSECONDS); // setting only lifespan MetadataValue<String> k1 = remoteCache.getWithMetadata("k1"); assertTrue(k1.getValue().equals("v1")); // microseconds converted to seconds assertTrue(k1.getLifespan() == 10); assertTrue(k1.getMaxIdle() == -1);{code} fails with: {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[5] returned server error (status=0x85): java.lang.ClassCastException: org.infinispan.container.entries.RepeatableReadEntry can not be cast to org.infinispan.container.entries.InternalCacheEntry at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143) at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99) at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) at org.infinispan.client.hotrod.impl.operations.AbstractKeyOperation.sendKeyOperation(AbstractKeyOperation.java:52) at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:35) at org.infinispan.client.hotrod.impl.operations.GetWithMetadataOperation.executeOperation(GetWithMetadataOperation.java:23) at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.getWithMetadata(RemoteCacheImpl.java:145){code} Works with isolation="READ_COMMITED"/"NONE" or with no <locking> at all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3307) Fix Stackoverflow error in CHMv8

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3307?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3307: ---------------------------------------- Updating to 1.110 seems to have [resurfaced an old tree bin bug|http://cs.oswego.edu/pipermail/concurrency-interest/2013-July/011599....]. > Fix Stackoverflow error in CHMv8 > -------------------------------- > > Key: ISPN-3307 > URL: https://issues.jboss.org/browse/ISPN-3307 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > Fix StackOverflow issue in CHMv8 implementation: > http://cs.oswego.edu/pipermail/concurrency-interest/2013-July/011541.html > Current version is 1.110, so update to that: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/Concurren... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3307) Fix Stackoverflow error in CHMv8

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3307?page=com.atlassian.jira.plugin.... ] Work on ISPN-3307 started by Galder Zamarreño. > Fix Stackoverflow error in CHMv8 > -------------------------------- > > Key: ISPN-3307 > URL: https://issues.jboss.org/browse/ISPN-3307 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.3.0.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > Fix StackOverflow issue in CHMv8 implementation: > http://cs.oswego.edu/pipermail/concurrency-interest/2013-July/011541.html > Current version is 1.110, so update to that: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/Concurren... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3051) Allow configuring the number of segments per node

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3051?page=com.atlassian.jira.plugin.... ] Work on ISPN-3051 started by Dan Berindei. > Allow configuring the number of segments per node > ------------------------------------------------- > > Key: ISPN-3051 > URL: https://issues.jboss.org/browse/ISPN-3051 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Guillermo GARCIA OCHOA > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Alpha2, 6.0.0.Final > > > This should allow for the following use cases: > - a node to take more load > - a node to take no load > A simple way for specifying this would be to configure a load factor per node, e.g. more powerful machine would be 2*x and that would mean that it would take twice the load of an "ordinary" machine in the cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013