September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3290) Redesign CacheStore API

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3290?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-3290. --------------------------------- Resolution: Done > Redesign CacheStore API > ----------------------- > > Key: ISPN-3290 > URL: https://issues.jboss.org/browse/ISPN-3290 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Priority: Critical > Fix For: 6.0.0.Final, 6.0.0.Alpha4 > > > the cache store API should be redesigned in the scope of 6.0. See all the related JIRAs for requirements. > Also a discussion has been started here: https://community.jboss.org/wiki/CacheLoaderAndCacheStoreSPIRedesign -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3402) Add JDBC Cache Store config to RHQ plugin

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3402?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3402: -------------------------------- Assignee: William Burns (was: Tristan Tarrant) > Add JDBC Cache Store config to RHQ plugin > ----------------------------------------- > > Key: ISPN-3402 > URL: https://issues.jboss.org/browse/ISPN-3402 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, Server > Reporter: William Burns > Assignee: William Burns > Fix For: 6.0.0.Alpha2 > > > ISPN-3350 was added to enhance some of the RHQ endpoints to allow for better runtime configuration support. However ISPN-3290 is also concurrently changing cache stores. Some changes for ISPN-3290 were mentioned to be possibly changing how the JDBC cache stores are configured and as such this has been excluded from ISPN-3350 to not implement it twice. > This is just to add in the support JDBC cache stores as they are missing. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3296) Total Order check list

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3296?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3296: -------------------------------- Fix Version/s: 6.1.0.Final (was: 6.0.0.CR1) > Total Order check list > ---------------------- > > Key: ISPN-3296 > URL: https://issues.jboss.org/browse/ISPN-3296 > Project: Infinispan > Issue Type: Task > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 6.1.0.Final > > > Issues found in Cloud-TM. Check if they happen here and create a JIRA for each of them > * IgnoreExtraResponseFilter is not needed anymore. > * missing argument log message > * TimeoutException, when happens, it is ignored and the transaction is processed normally > * TimeoutException can block the total order chain (all system is blocked!) > * port the testTimeoutCleanup from cloudtm to master -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3300) PutForExternalRead doesn't supress exceptions with TotalOrder

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3300?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3300: -------------------------------- Fix Version/s: (was: 6.0.0.CR1) > PutForExternalRead doesn't supress exceptions with TotalOrder > ------------------------------------------------------------- > > Key: ISPN-3300 > URL: https://issues.jboss.org/browse/ISPN-3300 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > > {{putForExternalRead}} is supposed to suppress any exceptions, but that doesn't work with Total Order caches. > Normally exceptions are suppressed in {{InvocationInterceptor.handleAll}} because the PFER PutKeyValueCommand has the FAIL_SILENTLY flag, but with TO the PFER is executed transactionally and the flag is not passed to the PrepareCommand. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3396) Multiple classloader key store/lookup fails, even with storeAsBinary

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3396?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3396: -------------------------------- Fix Version/s: (was: 6.0.0.CR1) > Multiple classloader key store/lookup fails, even with storeAsBinary > -------------------------------------------------------------------- > > Key: ISPN-3396 > URL: https://issues.jboss.org/browse/ISPN-3396 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 5.3.0.Final, 6.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Same key, multiple classloaders. Storing from one classloader cannot be found from the other, even when storeAsBinary is enabled (even with defensive=true). [IRC chat debugging issue|https://gist.github.com/galderz/63163644fee0c27d66c7]. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3541) Purge is not working for file-store

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-3541?page=com.atlassian.jira.plugin.... ] Jakub Markos updated ISPN-3541: ------------------------------- Affects Version/s: 6.0.0.Beta1 > Purge is not working for file-store > ----------------------------------- > > Key: ISPN-3541 > URL: https://issues.jboss.org/browse/ISPN-3541 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Beta1 > Reporter: Jakub Markos > Assignee: Mircea Markus > > When using this configuration (notice the purge=true) > {code:xml} > <local-cache name="default" start="EAGER" batching="false"> > <file-store name="hello" > passivation="true" > relative-to="temp" > path="${cachestore.name}" > purge="true"/> > </local-cache> > {code} > and running this test > {code} > for (int i = 0; i < 3; i++) { > cache.put("k" + i, i); > } > controller.stop(CONTAINER); // stops the server > controller.start(CONTAINER); > for (int i = 0; i < 3; i++) { > System.out.println("k" + i + ": " + cache.get("k" + i)); > } > {code} > the entries can be read even after server restart: > {quote} > k0: 0 // expecting null here > k1: 1 // expecting null here > k2: 2 // expecting null here > {quote} > Worked fine with DR4, not with ER1. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3541) Purge is not working for file-store

by Jakub Markos (JIRA)

[ https://issues.jboss.org/browse/ISPN-3541?page=com.atlassian.jira.plugin.... ] Jakub Markos commented on ISPN-3541: ------------------------------------ JDG 6.2.0.ER1 (Infinispan version: Infinispan 'Infinium' 6.0.0.Beta1-redhat-1) > Purge is not working for file-store > ----------------------------------- > > Key: ISPN-3541 > URL: https://issues.jboss.org/browse/ISPN-3541 > Project: Infinispan > Issue Type: Bug > Reporter: Jakub Markos > Assignee: Mircea Markus > > When using this configuration (notice the purge=true) > {code:xml} > <local-cache name="default" start="EAGER" batching="false"> > <file-store name="hello" > passivation="true" > relative-to="temp" > path="${cachestore.name}" > purge="true"/> > </local-cache> > {code} > and running this test > {code} > for (int i = 0; i < 3; i++) { > cache.put("k" + i, i); > } > controller.stop(CONTAINER); // stops the server > controller.start(CONTAINER); > for (int i = 0; i < 3; i++) { > System.out.println("k" + i + ": " + cache.get("k" + i)); > } > {code} > the entries can be read even after server restart: > {quote} > k0: 0 // expecting null here > k1: 1 // expecting null here > k2: 2 // expecting null here > {quote} > Worked fine with DR4, not with ER1. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3183) HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3183?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3183: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/158 > HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS > ----------------------------------------------------------------------------------- > > Key: ISPN-3183 > URL: https://issues.jboss.org/browse/ISPN-3183 > Project: Infinispan > Issue Type: Bug > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.CR1 > > Attachments: 52to52sourceTrace, 52to52targetTrace, 52to53sourceTrace, 52to53targetTrace > > > Scenario (typical for rollups): > Start source node, put entries. > Start target node which is pointing to source (source is his RemoteCacheStore now) and try to get entries. > For 5.2 to 5.2 working perfectly. > For 5.2 source and 5.3 target -- we have problems here. > Sorry that I can't provide any valuable info beside TRACEs. > 4 TRACE logs -- rollups from 5.2 to 5.2 source log and target log + rollups from 5.2 to 5.3 source log and target log. > Very quick summary: > 5.2 to 5.2 on target: Entry exists in loader? true > 5.2 to 5.3 on targer: > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Exists in context? null > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Retrieved from container null > What changed in RemoteCacheStore. What changed in HotRod? Any idea? Let me know, thank you! > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3467) Remove support for strictPeerToPeer = true

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3467?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3467: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2094 > Remove support for strictPeerToPeer = true > ------------------------------------------ > > Key: ISPN-3467 > URL: https://issues.jboss.org/browse/ISPN-3467 > Project: Infinispan > Issue Type: Task > Components: Configuration, RPC, Server > Affects Versions: 6.0.0.Alpha3 > Reporter: Dan Berindei > Assignee: Dan Berindei > > Setting {{transport.strictPeerToPeer = true}} doesn't really do anything with dist caches with L1 disabled, as commands are replicated only to members of the cache. With L1 enabled, writes/txs may or may not fail, depending on if there are any L1 requestors for the modified keys and on the value of {{clustering.l1.invalidationThreshold}} - unpredictable, so more harmful than useful. > With repl caches, the setting does work as advertised: even if the cache topology contains only the nodes with the cache running, the writes/txs are sent to all the nodes in the cluster, and they will fail if the cache is not running on one of them. On the other hand, in order to retry the operation, the users would have to wait for the cache's topology to contain all the nodes in the cluster - so if they need to ensure that a cache is present on all the nodes in the cluster, they could check that {{RpcManager.getMembers().equals(Transport.getMembers()}} directly. > So we should remove the {{transport.strictPeerToPeer}} setting, although we could mark it as deprecated and log a warning for the time being. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3183) HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3183?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3183: ---------------------------------- Fix Version/s: 6.0.0.Beta2 (was: 6.0.0.CR1) > HotRod RollUps from 5.2 to 5.3 -- target can't obtain formerly stored data from RCS > ----------------------------------------------------------------------------------- > > Key: ISPN-3183 > URL: https://issues.jboss.org/browse/ISPN-3183 > Project: Infinispan > Issue Type: Bug > Reporter: Tomas Sykora > Assignee: Tristan Tarrant > Priority: Critical > Labels: jdg62blocker > Fix For: 6.0.0.Beta2 > > Attachments: 52to52sourceTrace, 52to52targetTrace, 52to53sourceTrace, 52to53targetTrace > > > Scenario (typical for rollups): > Start source node, put entries. > Start target node which is pointing to source (source is his RemoteCacheStore now) and try to get entries. > For 5.2 to 5.2 working perfectly. > For 5.2 source and 5.3 target -- we have problems here. > Sorry that I can't provide any valuable info beside TRACEs. > 4 TRACE logs -- rollups from 5.2 to 5.2 source log and target log + rollups from 5.2 to 5.3 source log and target log. > Very quick summary: > 5.2 to 5.2 on target: Entry exists in loader? true > 5.2 to 5.3 on targer: > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Exists in context? null > 16:21:41,508 TRACE [org.infinispan.container.EntryFactoryImpl] (HotRodServerWorker-2) Retrieved from container null > What changed in RemoteCacheStore. What changed in HotRod? Any idea? Let me know, thank you! > -- 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, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013