June 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3165) Adding a programmatic configuration test for the MongoDB cache store

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3165?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3165: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Adding a programmatic configuration test for the MongoDB cache store > -------------------------------------------------------------------- > > Key: ISPN-3165 > URL: https://issues.jboss.org/browse/ISPN-3165 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Guillaume Scheibel > Assignee: Guillaume Scheibel > Priority: Minor > Labels: cache-store, mongodb, test > -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3135) Cleanup mongodb databases created by tests

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3135?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3135: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Cleanup mongodb databases created by tests > ------------------------------------------ > > Key: ISPN-3135 > URL: https://issues.jboss.org/browse/ISPN-3135 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 5.3.0.Beta2, 5.3.0.CR1 > Reporter: Mircea Markus > Assignee: Guillaume Scheibel > > ATM the MongoDB caches Store creates a database for each run instance, database name being an UUID in order to make sure that multiple tests connecting to the same mongo instance don't collide. > This database is not deleted on shutdown causing the disk to get full quickly. > It should be deleted and looking at the Mongodb java API the way to do it seems to be this: http://api.mongodb.org/java/2.10.1/com/mongodb/Mongo.html#dropDatabase(ja... -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3153) REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3153?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3153: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > REST endpoint does not return Last-modified header for GET operation if the entry was stored via HotRod or Embedded cache > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3153 > URL: https://issues.jboss.org/browse/ISPN-3153 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > When an entry is stored via HotRod an embedded cache, and later retrieved via REST,the Last-modified header looks like this: > Last Modified: null > Another observation is that when the entry is stored via REST and retrieved via REST again, the Last-modified header is: > Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT > This is obviously wrong and this was working correctly with JDG-server which contained ISPN 5.2. OTOH, when I set "timeToLiveSeconds" header on the request, the Last-modified is properly set (not to 1970). -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3154) REST endpoint does not return correct Expiry header for GET opeartion when the key is stored via HotRod or embedded cache

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3154?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3154: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > REST endpoint does not return correct Expiry header for GET opeartion when the key is stored via HotRod or embedded cache > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3154 > URL: https://issues.jboss.org/browse/ISPN-3154 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Beta2 > Reporter: Martin Gencur > Assignee: Galder Zamarreño > Fix For: 5.3.0.Final > > > The expiry header is not sent back at all if the entry was stored via HotRod or Embedded cache. It is sent back correctly only if the entry was stored via REST with timToLiveSeconds set. > The following test fails if added to EmbeddedRestHotRodTest class: > {code:java} > public void testHotRodEmbeddedPutRestGetExpiry() throws Exception { > final String key = "8"; > final String key2 = "9"; > // 1. Put with HotRod > assertEquals(null, cacheFactory.getHotRodCache().put(key, "v1", 5, TimeUnit.SECONDS)); > // 2. Put with Embedded > assertEquals(null, cacheFactory.getEmbeddedCache().put(key2, "v2", 5, TimeUnit.SECONDS)); > // 3. Get with REST key > HttpMethod get1 = new GetMethod(cacheFactory.getRestUrl() + "/" + key); > cacheFactory.getRestClient().executeMethod(get1); > assertEquals(HttpServletResponse.SC_OK, get1.getStatusCode()); > assertNotNull(get1.getResponseHeader("Expires")); > //^^^fails here - returns null > // 4. Get with REST key2 > HttpMethod get2 = new GetMethod(cacheFactory.getRestUrl() + "/" + key2); > cacheFactory.getRestClient().executeMethod(get2); > assertEquals(HttpServletResponse.SC_OK, get2.getStatusCode()); > assertNotNull(get2.getResponseHeader("Expires")); > //^^^fails here - returns null > } > {code} -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-2990: ------------------------------------- [~rpwburns] My bigest concern is that the problem is reproductible with *sync* caches as well. For async caches the user should expect inconstancies by their nature and the l1 invalidation failure is more of an suboptimal case. > L1ManagerImpl doesn't reliably invalidate with async caches > ----------------------------------------------------------- > > Key: ISPN-2990 > URL: https://issues.jboss.org/browse/ISPN-2990 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Labels: onboard > > B is owner of k,v1 > A has k,v1 in L1 > 1. TX: A puts k,v2 > 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit) > 3. TX: A removes k,v1 from L1 > 4. A putForExternalRead k,v1 and has it in L1 again > 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin > Result: A has k,v1 and B has k,v2 > Solution: For async caches send invalidation to origin too. > The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-2990 at 6/5/13 2:03 PM: ------------------------------------------------------------- thinking more about this doesn't have to do with async caches, but just the way two messages are ordered: - responses to get - invalidation messages. was (Author: mircea.markus): thinking more about this doesn't have to do with async caches as at all, but just the way two messages are ordered: - responses to get - invalidation messages. > L1ManagerImpl doesn't reliably invalidate with async caches > ----------------------------------------------------------- > > Key: ISPN-2990 > URL: https://issues.jboss.org/browse/ISPN-2990 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Labels: onboard > > B is owner of k,v1 > A has k,v1 in L1 > 1. TX: A puts k,v2 > 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit) > 3. TX: A removes k,v1 from L1 > 4. A putForExternalRead k,v1 and has it in L1 again > 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin > Result: A has k,v1 and B has k,v2 > Solution: For async caches send invalidation to origin too. > The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2990) L1ManagerImpl doesn't reliably invalidate with async caches

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2990?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-2990: ------------------------------------- Looking closer it as as Mircea suspected that an OOB message (ClusteredGetCommand) is being sent while the RemoveCommand (in band) is still being processed. The L1 cache is only invalidated for nodes that requested the given key and are not the updating node. The latter is because the updating node just updates it's L1 cache directly and doesn't query from any of the owning nodes. So in this case it is very simple to reproduce: {code} A owns key k with a value of 1 B removes key k (done async) B gets key k (receives value 1 since async hasn't completed) and stores in it's L1 cache A finally removes k and invalidates all known L1 cache values except B's as it was the requestor {code} Just a simple {code} cache.remove(k); cache.get(k); {code} would reproduce the issue. > L1ManagerImpl doesn't reliably invalidate with async caches > ----------------------------------------------------------- > > Key: ISPN-2990 > URL: https://issues.jboss.org/browse/ISPN-2990 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.1.Final > Reporter: Sebastian Tusk > Assignee: William Burns > Labels: onboard > > B is owner of k,v1 > A has k,v1 in L1 > 1. TX: A puts k,v2 > 2. TX: A sends async PrepareCommand k,v2 to B (one-phase-commit) > 3. TX: A removes k,v1 from L1 > 4. A putForExternalRead k,v1 and has it in L1 again > 5. TX: B executes PrepareCommand k,v2 but doesn't send invalidation to origin > Result: A has k,v1 and B has k,v2 > Solution: For async caches send invalidation to origin too. > The problem is that the owner updates the cache entry asynchronously. This gives the origin of the transaction time to request the entry. Here an outdated version is received and placed in L1. The owner never invalidates the entry and as result the cache is inconsistent. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3195) Override server aesh to 0.33.1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3195?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3195: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/113 > Override server aesh to 0.33.1 > ------------------------------ > > Key: ISPN-3195 > URL: https://issues.jboss.org/browse/ISPN-3195 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.CR1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.CR2 > > > Infinispan Library uses AEsh 0.33.1 (same as EAP 6.1), but the server is based on AS 7.2, so we need to override the version for compatibility. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3195) Override server aesh to 0.33.1

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3195: ------------------------------------- Summary: Override server aesh to 0.33.1 Key: ISPN-3195 URL: https://issues.jboss.org/browse/ISPN-3195 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 5.3.0.CR1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 5.3.0.CR2 Infinispan Library uses AEsh 0.33.1 (same as EAP 6.1), but the server is based on AS 7.2, so we need to override the version for compatibility. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3073) Remove deprecated configuration elements from default JGroups config

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3073?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-3073. ----------------------------------- Resolution: Done ISPN-3080 actually took care of the deprecated elements too > Remove deprecated configuration elements from default JGroups config > -------------------------------------------------------------------- > > Key: ISPN-3073 > URL: https://issues.jboss.org/browse/ISPN-3073 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Minor > 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, 7 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