June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3227) Server loader configuration breaks when properties are specified

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3227?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3227: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] Yes, there appears to be a problem with the mead repo and John Casey is looking into it. Will let you know as soon as it is fixed. Tristan On 06/20/2013 04:19 PM, Shay Matasaro wrote: > Hi, > > I am trying to build the JDG 6.1.0GA tag server, using these git repos: > | > git://git.app.eng.bos.redhat.com/srv/git/infinispan/infinispan-server.git > > But the builds fail because the source is looking for dependencies ending with 5.2.4-redhat-1, but the on-line brew maven repo only has||5.2.4-redhat-3, and I checked all 6 repos. > > |is it a bug in the paren pom, or is there another on-line brew repo? > > -- > Thanks, > Shay > Server loader configuration breaks when properties are specified > ---------------------------------------------------------------- > > Key: ISPN-3227 > URL: https://issues.jboss.org/browse/ISPN-3227 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.6.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.7.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3241) Memcached server should not redefine its cache if it already exists

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3241?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3241: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.2.7.Final Resolution: Done > Memcached server should not redefine its cache if it already exists > ------------------------------------------------------------------- > > Key: ISPN-3241 > URL: https://issues.jboss.org/browse/ISPN-3241 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.6.Final, 5.3.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.7.Final, 5.3.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3241) Memcached server should not redefine its cache if it already exists

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3241?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3241: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 975361|https://bugzilla.redhat.com/show_bug.cgi?id=975361] The fix is included in https://brewweb.devel.redhat.com/taskinfo?taskID=5930617 and in particular: http://download.devel.redhat.com/brewroot/work/tasks/617/5930617/org/infi... > Memcached server should not redefine its cache if it already exists > ------------------------------------------------------------------- > > Key: ISPN-3241 > URL: https://issues.jboss.org/browse/ISPN-3241 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.6.Final, 5.3.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3241) Memcached server should not redefine its cache if it already exists

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3241?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3241: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 975361|https://bugzilla.redhat.com/show_bug.cgi?id=975361] from ASSIGNED to MODIFIED > Memcached server should not redefine its cache if it already exists > ------------------------------------------------------------------- > > Key: ISPN-3241 > URL: https://issues.jboss.org/browse/ISPN-3241 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.6.Final, 5.3.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3241) Memcached server should not redefine its cache if it already exists

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3241?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3241: ----------------------------------------------- Jimmy Wilson <jawilson(a)redhat.com> made a comment on [bug 975361|https://bugzilla.redhat.com/show_bug.cgi?id=975361] Upstream PR: https://github.com/infinispan/infinispan/pull/1911 > Memcached server should not redefine its cache if it already exists > ------------------------------------------------------------------- > > Key: ISPN-3241 > URL: https://issues.jboss.org/browse/ISPN-3241 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 5.2.6.Final, 5.3.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.Final > > -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2835) Issues w/ M/R test cases if cache are not explicitly started on all nodes

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Dan Berindei resolved ISPN-2835. -------------------------------- Resolution: Cannot Reproduce Bug This is not a problem in the test setup, not in M/R. The test uses {{AbstractCacheTest.getDefaultClusteredCacheConfig()}} to construct the configuration, which disables state transfer. If the cache isn't started on both nodes before the keys are inserted in the cache, one of the nodes will not receive any entries via state transfer and naturally the M/R task won't find any entries there. I fixed Galder's test by ading this line in the createCacheManagers method: {code} builder.clustering().stateTransfer().fetchInMemoryState(true); {code} > Issues w/ M/R test cases if cache are not explicitly started on all nodes > ------------------------------------------------------------------------- > > Key: ISPN-2835 > URL: https://issues.jboss.org/browse/ISPN-2835 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Execution and Map/Reduce > Reporter: Ray Tsang > Assignee: Dan Berindei > Labels: onboard > Fix For: 5.3.0.Final > > Attachments: infinispan.log, mr-test-src.zip > > > I ran into some issues while using M/R. The gist of the issue I was seeing is that: > Start a cluster of Embedded Caches, like 4 nodes > Put in 100 elements > Run a simple M/R job to count the number of keys > If I run the M/R job using the node I'm inserting elements into as coordinator - the result is 100 > But if I run the M/R job using a different node as coordinator, the result is less than 100 > More interestingly, I can pause for 5 seconds and run the M/R jobs again, the results are always less than 100 > This behavior doens't occur if I explicitly run cacheManager.getCache() for each of the nodes... -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3214) When non owner updates non-tx dist cache the L1 is not updated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3214?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3214: ------------------------------------- Actually looking into this, it would require locking the L1 cache before the remote invocation and after. This may be okay? With the changes I have for ISPN-3197, we only update the L1 cache on a read if it is able to acquire the lock immediately. But this could cause a L1 update to miss if a conditional write occurs and fails since it would no longer update the L1 but held the lock - acceptable? Also this would be a similar regression to how locking would work in that it would acquire the local lock first before the remote. But I believe this should be fine since the issue prior was if it acquired the remote owner locks in a different order, causing a deadlock. Now we only acquire the primary owner lock instead. > When non owner updates non-tx dist cache the L1 is not updated > -------------------------------------------------------------- > > Key: ISPN-3214 > URL: https://issues.jboss.org/browse/ISPN-3214 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > > Non tx DIST caches only add/update the L1 on a GetKeyValueCommand. The tx DIST cache updates the L1 cache on write operations as well. This should be consistent and is a minor performance issue. -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3243) Inconsistent behaviour of operations HotRod.clear vs Memcached.flushAll wrt CacheStore

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3243?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3243: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=976402 > Inconsistent behaviour of operations HotRod.clear vs Memcached.flushAll wrt CacheStore > -------------------------------------------------------------------------------------- > > Key: ISPN-3243 > URL: https://issues.jboss.org/browse/ISPN-3243 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.6.Final, 5.3.0.Final > Reporter: Michal Linhard > Assignee: Mircea Markus > > Affecting 5.3.0-SNAPSHOT and 5.2.x branch > When using hot rod client the clear() operation deletes all entries also in the cache store > When using memcached client the flush_all operation deletes entries only in the memory > hotrod behaviour: > https://github.com/infinispan/infinispan/blob/5.3.x/server/hotrod/src/mai... > memcached behaviour: > https://github.com/infinispan/infinispan/blob/5.3.x/server/memcached/src/... > shouldn't they be consistent ? -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3261) Extract clustering functionality from core to infinispan-clustering

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3261: ------------------------------------- Summary: Extract clustering functionality from core to infinispan-clustering Key: ISPN-3261 URL: https://issues.jboss.org/browse/ISPN-3261 Project: Infinispan Issue Type: Sub-task Components: Build process, Core API Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 6.0.0.Alpha1 -- 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

11 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3229) L1 cache entries should not be passivated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3229?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3229: ------------------------------------- Ah thanks for the tip, that should work nicely then :) > L1 cache entries should not be passivated > ----------------------------------------- > > Key: ISPN-3229 > URL: https://issues.jboss.org/browse/ISPN-3229 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: Mircea Markus > Attachments: DistSyncL1PassivationFuncTest.java > > > L1 entries are stored in the same data container as the real entries. These can be evicted which is fine, however we don't want them to be passivated as this could be costly to write/read from the cache store. We should either prevent L1 cache entries from being passivated or have an option to allow for it. > Currently L1 entries are not differentiated from other entries except through the fact that they are mortal, which is used for other operations as well, which means they would need a placeholder of some kind to tell the container this is a L1 entry. -- 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

11 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2013