August 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3390) SingleFileCacheStore.start() fails if cache name contains File.separator

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3390?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3390: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > SingleFileCacheStore.start() fails if cache name contains File.separator > ------------------------------------------------------------------------- > > Key: ISPN-3390 > URL: https://issues.jboss.org/browse/ISPN-3390 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 6.0.0.Alpha2 > > > Using the old FileCacheStore, if the cache name contained File.separator, then the location of the file cache store included corresponding subdirectories. > e.g. > If my cache name is "myhost/mydeployment.war", then the file cache store includes a subdirectory "myhost". > In the new SingleFileCacheStore implementation, however, start() fails because only the directories contained within the location are created. When the File object is constructed using the cache name, if the cache name contains a File.separator, those subdirectories are *not* created, and start() fails with the following message: > "Directory ... does not exist and cannot be created!" > As I see it, this can be fixed in 1 of 2 ways: > 1. Escape any file separators in the cache name when constructing the file name > 2. Create the necessary subdirectories on the File object created using the cache name -- 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-3276) Remove usages of CacheLoaderConfig

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3276?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3276: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove usages of CacheLoaderConfig > ---------------------------------- > > Key: ISPN-3276 > URL: https://issues.jboss.org/browse/ISPN-3276 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha1 > Reporter: Navin Surtani > Assignee: Navin Surtani > > As part of the Configuration migration, we need to remove all usages of CacheLoaderConfig and change them to CacheLoaderConfiguration usages. > This will involve making changes to how implementations of org.infinispan.loaders.CacheLoader work along with their respective constructors. -- 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-3343) Write up CacheLoaderConfiguration and corresponding Builder for Lucene module.

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3343?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-3343. --------------------------------- Resolution: Done > Write up CacheLoaderConfiguration and corresponding Builder for Lucene module. > ------------------------------------------------------------------------------- > > Key: ISPN-3343 > URL: https://issues.jboss.org/browse/ISPN-3343 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Loaders and Stores, Lucene Directory > Reporter: Navin Surtani > Assignee: Navin Surtani > Fix For: 6.0.0.Alpha2 > > > The Lucene module needs an updated Configuration (and Builder) for the class org.infinispan.lucene.cachestore.LuceneCacheLoader. It currently uses an implementation of CacheLoaderConfig which is to be wiped from 6.0.0 onwards. -- 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-3391) Upgrade to JBoss Marshalling 2.0.0.Beta1

by Dan Berindei (JIRA)

Dan Berindei created ISPN-3391: ---------------------------------- Summary: Upgrade to JBoss Marshalling 2.0.0.Beta1 Key: ISPN-3391 URL: https://issues.jboss.org/browse/ISPN-3391 Project: Infinispan Issue Type: Component Upgrade Components: Build process, Marshalling Affects Versions: 6.0.0.Alpha1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 6.0.0.Alpha2 Quoting David Lloyd: The following things should be known about this update: * There are some API incompatibilities (in particular, Creators are gone, and Externalizers changed a little bit) * The binary protocol is 100% identical 2.x can interoperate with 1.x over the wire with no problems * The changes to Infinispan seem pretty minimal -- 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-3373) HotRod topology cache should allow disabling awaitInitialTransfer

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3373?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3373: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > HotRod topology cache should allow disabling awaitInitialTransfer > ----------------------------------------------------------------- > > Key: ISPN-3373 > URL: https://issues.jboss.org/browse/ISPN-3373 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols, Server > Affects Versions: 6.0.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Alpha2 > > > When a server with a hotrod endpoint joins a cluster where state transfer has been disabled (ISPN-3140), waiting for initial state transfer should also be disabled on the topology cache, otherwise failures occur. -- 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-3282) Optimize get() for null values

by Erik Salter (JIRA)

[ https://issues.jboss.org/browse/ISPN-3282?page=com.atlassian.jira.plugin.... ] Erik Salter reassigned ISPN-3282: --------------------------------- Assignee: Erik Salter (was: Mircea Markus) > Optimize get() for null values > ------------------------------ > > Key: ISPN-3282 > URL: https://issues.jboss.org/browse/ISPN-3282 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Affects Versions: 5.2.6.Final > Reporter: Erik Salter > Assignee: Erik Salter > > The current implementation of a get() operation for DIST-mode caches will return the first valid response if there is a value present. Null values, though, require all owners to return. > For certain cache modes, null value handling can be optimized to be encapsulated in a SuccessfulResponse so that the operation can return on the first instance. -- 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-3282) Optimize get() for null values

by Erik Salter (JIRA)

[ https://issues.jboss.org/browse/ISPN-3282?page=com.atlassian.jira.plugin.... ] Erik Salter commented on ISPN-3282: ----------------------------------- https://github.com/infinispan/infinispan/pull/1997 > Optimize get() for null values > ------------------------------ > > Key: ISPN-3282 > URL: https://issues.jboss.org/browse/ISPN-3282 > Project: Infinispan > Issue Type: Enhancement > Components: Core API > Affects Versions: 5.2.6.Final > Reporter: Erik Salter > Assignee: Mircea Markus > > The current implementation of a get() operation for DIST-mode caches will return the first valid response if there is a value present. Null values, though, require all owners to return. > For certain cache modes, null value handling can be optimized to be encapsulated in a SuccessfulResponse so that the operation can return on the first instance. -- 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-3390) SingleFileCacheStore.start() fails if cache name contains File.separator

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-3390?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-3390: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1996 Fixed using approach #2. > SingleFileCacheStore.start() fails if cache name contains File.separator > ------------------------------------------------------------------------- > > Key: ISPN-3390 > URL: https://issues.jboss.org/browse/ISPN-3390 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Using the old FileCacheStore, if the cache name contained File.separator, then the location of the file cache store included corresponding subdirectories. > e.g. > If my cache name is "myhost/mydeployment.war", then the file cache store includes a subdirectory "myhost". > In the new SingleFileCacheStore implementation, however, start() fails because only the directories contained within the location are created. When the File object is constructed using the cache name, if the cache name contains a File.separator, those subdirectories are *not* created, and start() fails with the following message: > "Directory ... does not exist and cannot be created!" > As I see it, this can be fixed in 1 of 2 ways: > 1. Escape any file separators in the cache name when constructing the file name > 2. Create the necessary subdirectories on the File object created using the cache name -- 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-3366) Data loss when entry forwarding to primary owner and primary owner shutdown

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3366?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3366: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1995 Always reply with a CacheNotFoundResponse when the requested cache is not running. Throw a RemoteException(NamedCacheNotFoundException) from RpcManagerImpl, if strictPeerToPeer = true. Throw an OutdatedTopologyException from NonTxConcurrentDistributionInterceptor, if strictPeerToPeer = false. Catch OutdatedTopologyException in StateTransferInterceptor and retry the operation. > Data loss when entry forwarding to primary owner and primary owner shutdown > --------------------------------------------------------------------------- > > Key: ISPN-3366 > URL: https://issues.jboss.org/browse/ISPN-3366 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.4.Final, 6.0.0.Alpha1 > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Priority: Critical > Attachments: ISPN-3366-logs.zip > > > Looks like a problem in entry forwarding. > Here is test scenario: > * DIST numOwners=2, start with 4 nodes cluster then normal shutdown 1 node during load > * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total > After the test run, the numberOfEntries on each node are: > * node1: 26608 > * node2: 26622 > * node3: 26746 > * node4: 0 > Total is 79976 and HotRod client received 11 errors, so 79976 + (11 * 2) = 79998. It means 1 entry is completely missing. > Let's take a look at the missing entry, hash(thread16key59) = 574ff563. > Current CH: owners(574ff563) are [node4, node1] > The events sequence is: > * hotrod -> node1 > * node1 forwarding it to primary owner node4 > * node4 doesn't process the forwarded entry, shutdown > Result owners(7c29bccb) is [] empty. This entry is completely lost without any errors. -- 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-3357) Insufficient owners with putIfAbsent during node join rebalance

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3357?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3357: ----------------------------------- I have written down a test in library mode exhibiting this behaviour. Please, let me know as fix is ready, I'll try to check that. > Insufficient owners with putIfAbsent during node join rebalance > --------------------------------------------------------------- > > Key: ISPN-3357 > URL: https://issues.jboss.org/browse/ISPN-3357 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.4.Final, 6.0.0.Alpha1 > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Priority: Critical > Attachments: 7c29bccb.log > > > Here is test scenario: > * DIST numOwners=2, start with 3 nodes cluster then join 1 node during load > * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total > After the test run, the numberOfEntries on each node are: > * node1: 20074 > * node2: 19888 > * node3: 20114 > * node4: 18885 > Total is 78961, 1039 entries are missing. No error on HotRod client side so 80000 entries should be there. > Let's take a look at example missing entry, hash(thread01key151) = 7c29bccb. > Current CH: owners(7c29bccb) are [node1, node2] > Pending CH: owners(7c29bccb) are [node1, node2, node4] > Balanced CH: owners(7c29bccb) are [node1, node4] > The events sequence is: > * hotrod -> node1 > * node1 -> node2, node4 > * node2 committed entry > * node4 performed clustered get before write, got a value from node2 and will not commit the entry because this node thinks it's not changed/created > * node1 committed entry > * node2 invalidates the entry because it's no longer an owner > Result owners(7c29bccb) are only node1 and node4 is missing. This entry may be completely lost by further rebalances when node4 is donor for this segment. -- 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 August 2013