May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2855) Move JCache annotations from infinispan-cdi to infinispan-jcache module

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2855?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2855: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Move JCache annotations from infinispan-cdi to infinispan-jcache module > ----------------------------------------------------------------------- > > Key: ISPN-2855 > URL: https://issues.jboss.org/browse/ISPN-2855 > Project: Infinispan > Issue Type: Sub-task > Components: CDI integration, JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR1 > > > On top of moving the annotation support to the JSR-107 implementation infinispan-jcache module, enable jcache annotation TCK tests to be run from the integration test project called tck-runner under jcache/src/it. -- 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 Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2835?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2835: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > 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: Galder Zamarreño > Labels: onboard > Fix For: 5.3.0.CR1, 5.3.0.Final > > Attachments: 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-2810) In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2810?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2810: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > In REST, default values for maxIdleTimeSeconds and timeToLiveSeconds should be 0 > -------------------------------------------------------------------------------- > > Key: ISPN-2810 > URL: https://issues.jboss.org/browse/ISPN-2810 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Affects Versions: 5.2.0.Final > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR1 > > > Contrary to what ISPN-732 says, timeToLiveSeconds=0 and maxIdleTimeSeconds=0 are now treated correctly by the server and the entry is stored in the cache with the default lifespan/maxIdle. > But if the user PUTs or POSTs an entry and doesn't specify timeToLiveSeconds=0 and maxIdleTimeSeconds=0 explicitly, the entries are stored with infinite lifespan/maxIdle. -- 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-2809) Drop startServer.sh and use JDG harness to launch Infinispan servers

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2809?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2809: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Drop startServer.sh and use JDG harness to launch Infinispan servers > -------------------------------------------------------------------- > > Key: ISPN-2809 > URL: https://issues.jboss.org/browse/ISPN-2809 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Reporter: Mircea Markus > Assignee: Tristan Tarrant > Fix For: 5.3.0.CR1, 5.3.0.Final > > > this JIRA is practically about open sourcing JDG server harness code and use the same way of managing servers' lifecycle between ISPN and JDG. -- 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-2834) test failure: AtomicMapBackupTest

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2834?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2834: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > test failure: AtomicMapBackupTest > --------------------------------- > > Key: ISPN-2834 > URL: https://issues.jboss.org/browse/ISPN-2834 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication > Affects Versions: 5.2.2.Final > Reporter: Mircea Markus > Assignee: Mircea Markus > Labels: 5.2.x > Fix For: 5.3.0.CR1 > > -- 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-2802) Cache recovery fails due to missing responses

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2802?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2802: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Cache recovery fails due to missing responses > --------------------------------------------- > > Key: ISPN-2802 > URL: https://issues.jboss.org/browse/ISPN-2802 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.0.CR3 > Reporter: Radim Vansa > Assignee: Dan Berindei > Fix For: 5.3.0.CR1, 5.3.0.Final > > > When the cache recovery is started, the new coordinator sends CacheTopologyControlCommand.GET_STATUS to all nodes and waits for responses. However, I have a reproducible test-case where it always times out waiting for the responses. > Here are the logs (TRACE is not doable here, but I added some byteman traces - see topology.btm in the archive): http://dl.dropbox.com/u/103079234/recovery.zip > The problematic spot is on node3 at 05:37:57 receiving cluster view 34. > All nodes (except the one which is killed, in this case node1) respond quickly to the GET_STATUS command (see BYTEMAN Receiving - Received pairs, these are bound to command execution in CommandAwareRpcDispatcher), but some responses are not received on node3 (look for Receiving rsp bound to GroupRequest). > JGroups tracing could be useful here but it is not available (intensive logging often blocks on internal log4j locks and the node becomes unresponsive). > As mentioned above, the case is reproducible, therefore if you can suggest any particular BYTEMAN hook, I can try it. -- 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-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2950: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > In distributed mode cache store data should be read through the main data owner (vs directly from the store) > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-2950 > URL: https://issues.jboss.org/browse/ISPN-2950 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Priority: Critical > Labels: onboard > Fix For: 5.3.0.CR1, 5.3.0.Final > > > Dist cache with a cache store (shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawbacks: > - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this) > - if this is a local cache store, it might contain stale data which would be returned to the user > - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.) > This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated as well. -- 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-2926) MBean to access cache content

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2926?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2926: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > MBean to access cache content > ----------------------------- > > Key: ISPN-2926 > URL: https://issues.jboss.org/browse/ISPN-2926 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Affects Versions: 5.2.5.Final > Reporter: Edoardo Schepis > Assignee: Manik Surtani > Fix For: 5.3.0.CR1, 5.3.0.Final > > > It would be great to have a tool to access the cache and inspect it. > For troubleshooting, debugging or simply for monitoring, it would be very helpful to show the content of the cache using some kind of tool -- 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-2924) Update ConcurrentHashMapV8 and dependant classes

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2924?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2924: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > Update ConcurrentHashMapV8 and dependant classes > ------------------------------------------------ > > Key: ISPN-2924 > URL: https://issues.jboss.org/browse/ISPN-2924 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 5.3.0.CR1 > > > Update with latest changes in http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ -- 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-2906) SyncCacheListenerTest.testSyncTxRepl failing randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2906?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2906: -------------------------------- Fix Version/s: 5.3.0.CR1 (was: 5.3.0.Beta2) > SyncCacheListenerTest.testSyncTxRepl failing randomly > ----------------------------------------------------- > > Key: ISPN-2906 > URL: https://issues.jboss.org/browse/ISPN-2906 > Project: Infinispan > Issue Type: Bug > Components: Listeners, Transactions > Reporter: Galder Zamarreño > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.3.0.CR1 > > Attachments: SyncCacheListenerTest_age_is_null.log, testSyncTxRepl-0.log > > > {code}testSyncTxRepl(org.infinispan.replication.SyncCacheListenerTest) Time elapsed: 0.04 sec <<< FAILURE! > java.lang.AssertionError: "age" obtained from cache2 must be non-null > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) > at org.testng.AssertJUnit.assertNotNull(AssertJUnit.java:267) > at org.infinispan.replication.SyncCacheListenerTest.testSyncTxRepl(SyncCacheListenerTest.java:99) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722){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, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013