[JBoss JIRA] (ISPN-5025) Infinispan ArrayIndexOutOfBoundsException in ComponentMetadataPersister
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5025?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-5025.
---------------------------------
Resolution: Out of Date
> Infinispan ArrayIndexOutOfBoundsException in ComponentMetadataPersister
> ------------------------------------------------------------------------
>
> Key: ISPN-5025
> URL: https://issues.jboss.org/browse/ISPN-5025
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Uday Mareedu
>
> Hi Team,
> In my project we need to implement the caching for the application which is running in JBOSS. Basically I need to cache the objects from the servlet. I have downloaded the infinispan-7.0.2.Final-minimal to try it in eclipse.
> Below is the very sample code to try.
> import org.infinispan.Cache;
> import org.infinispan.manager.DefaultCacheManager;
> public class SimpleCaching {
> static void main(String args[]) {
> try {
> System.out.print("Start");
> Cache<Object, Object> c = new DefaultCacheManager().getCache();
> c.put("key", "value");
> c.putIfAbsent("key", "newValue");
> System.out.print(c.get("key"));
>
> } catch (Exception ex1) {
> System.out.println(ex1.getMessage());
> }
> }
> }
> I have added all the dependencies, but I am getting "Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 0
> at org.infinispan.factories.components.ComponentMetadataPersister.main(ComponentMetadataPersister.java:50)" exception.
> I am very new to this, can anyone explain where I am missing.
> Thanks in advance for your help!
> Regards,
> Uday Shankar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-5041) Random failure of test org.infinispan.distribution.ConcurrentStartWithReplTest.testSequence4
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5041?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-5041.
---------------------------------
Resolution: Out of Date
> Random failure of test org.infinispan.distribution.ConcurrentStartWithReplTest.testSequence4
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-5041
> URL: https://issues.jboss.org/browse/ISPN-5041
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.11.Final
> Environment: RHEL7
> Reporter: Richard Janík
> Priority: Minor
>
> I'm seeing a random (1 out of 20) failure of org.infinispan.distribution.ConcurrentStartWithReplTest.testSequence4 when a distributed cache fails to start because:
> {code}
> ISPN000210: Failed to request segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56] of cache d from node ConcurrentStartWithReplTest-NodeB-18005 (node will not be retried)
> {code}
> Stacktrace:
> {code}
> Error Message
> Method org.testng.internal.TestNGMethod.testSequence4() didn't finish within the time-out 60000
> Stacktrace
> org.testng.internal.thread.ThreadTimeoutException: Method org.testng.internal.TestNGMethod.testSequence4() didn't finish within the time-out 60000
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:197)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:436)
> at java.util.concurrent.FutureTask.get(FutureTask.java:198)
> at org.infinispan.distribution.ConcurrentStartWithReplTest.doTest(ConcurrentStartWithReplTest.java:161)
> at org.infinispan.distribution.ConcurrentStartWithReplTest.testSequence4(ConcurrentStartWithReplTest.java:137)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:619)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.InvokeMethodRunnable.runOne(InvokeMethodRunnable.java:46)
> at org.testng.internal.InvokeMethodRunnable.run(InvokeMethodRunnable.java:37)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:482)
> at java.util.concurrent.FutureTask.run(FutureTask.java:273)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1176)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
> at java.lang.Thread.run(Thread.java:853)
> {code}
> Standard output:
> {code}
> 014-11-26 15:19:18,021 WARN [InboundTransferTask] (transport-thread-2,ConcurrentStartWithReplTest-NodeA) ISPN000210: Failed to request segments [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 17, 16, 19, 18, 21, 20, 23, 22, 25, 24, 27, 26, 29, 28, 31, 30, 34, 35, 32, 33, 38, 39, 36, 37, 42, 43, 40, 41, 46, 47, 44, 45, 51, 50, 49, 48, 55, 54, 53, 52, 59, 58, 57, 56] of cache d from node ConcurrentStartWithReplTest-NodeB-18005 (node will not be retried)
> 2014-11-26 15:19:18,221 ERROR [StateConsumerImpl] (transport-thread-2,ConcurrentStartWithReplTest-NodeA) ISPN000208: No live owners found for segment 0 of cache d. Current owners are: [ConcurrentStartWithReplTest-NodeB-18005]. Faulty owners: [ConcurrentStartWithReplTest-NodeB-18005]
> ...
> 2014-11-26 15:19:18,268 ERROR [StateConsumerImpl] (transport-thread-2,ConcurrentStartWithReplTest-NodeA) ISPN000208: No live owners found for segment 56 of cache d. Current owners are: [ConcurrentStartWithReplTest-NodeB-18005]. Faulty owners: [ConcurrentStartWithReplTest-NodeB-18005]
> [testng-ConcurrentStartWithReplTest] Test testSequence4(org.infinispan.distribution.ConcurrentStartWithReplTest) failed.
> {code}
> Jenkins link:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-manu-infinisp...
> Configurations:
> jdk=ibm1.7 platform=RHEL7
> jdk=openjdk-1.6.0 platform=RHEL7
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-4876) API for obtaining cache metadata
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4876?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-4876.
---------------------------------
Resolution: Duplicate Issue
> API for obtaining cache metadata
> --------------------------------
>
> Key: ISPN-4876
> URL: https://issues.jboss.org/browse/ISPN-4876
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Tristan Tarrant
>
> Currently we have a number of "service" caches which store additional information about "primary" caches (e.g. protobuf schemas, indexes, topology). We might also want to store other additional information (configurations, metadata, etc).
> I think we can hijack the ClusterRegistry class to provide a standardized interface to obtain "service" caches based on a set of requirements (persistent/volatile, shared/private, etc) and apply well-defined configurations to them (e.g. security).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-4880) Distribution mode-friendly preloading
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4880?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4880:
----------------------------------
Fix Version/s: (was: 9.0.0.Alpha4)
> Distribution mode-friendly preloading
> -------------------------------------
>
> Key: ISPN-4880
> URL: https://issues.jboss.org/browse/ISPN-4880
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core, Loaders and Stores
> Affects Versions: 7.0.0.CR2
> Reporter: Dan Berindei
>
> For non-shared stores, we need a graceful restart to make sure each node receives the exact same segments after restart, and that keys aren't readable/writable until re recover all the segments.
> With a shared store, however, we could replace the implicit preload with an explicit preload that can be called by the user after the cluster is fully formed.
> Currently, preloading happens before the cache is a full member of the cluster, so it wants to load every key on every node. In a large cluster, that means most of the keys loaded by preload will be discarded as it joins and finds out it owns only a tiny slice of the data.
> Preloaded values might be out of date before the node becomes a full member (because writes on the existing nodes will update the shared store, but not the joiner's in-memory data). The only way to avoid that is to delete everything that was preloaded on join, meaning even more lost work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-4880) Distribution mode-friendly preloading
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4880?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-4880:
-------------------------------------
Assignee: William Burns
> Distribution mode-friendly preloading
> -------------------------------------
>
> Key: ISPN-4880
> URL: https://issues.jboss.org/browse/ISPN-4880
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core, Loaders and Stores
> Affects Versions: 7.0.0.CR2
> Reporter: Dan Berindei
> Assignee: William Burns
>
> For non-shared stores, we need a graceful restart to make sure each node receives the exact same segments after restart, and that keys aren't readable/writable until re recover all the segments.
> With a shared store, however, we could replace the implicit preload with an explicit preload that can be called by the user after the cluster is fully formed.
> Currently, preloading happens before the cache is a full member of the cluster, so it wants to load every key on every node. In a large cluster, that means most of the keys loaded by preload will be discarded as it joins and finds out it owns only a tiny slice of the data.
> Preloaded values might be out of date before the node becomes a full member (because writes on the existing nodes will update the shared store, but not the joiner's in-memory data). The only way to avoid that is to delete everything that was preloaded on join, meaning even more lost work.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-4777) Replace command not atomic in REPL_SYNC cache mode
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4777?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant closed ISPN-4777.
---------------------------------
Resolution: Out of Date
Won't fix this in 5.2.x
> Replace command not atomic in REPL_SYNC cache mode
> --------------------------------------------------
>
> Key: ISPN-4777
> URL: https://issues.jboss.org/browse/ISPN-4777
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.6.Final
> Reporter: Anuj Shah
> Assignee: Gustavo Fernandes
> Attachments: ReaderLockerTest.java
>
>
> This problem was discovered using the Lucene InfinispanDirectory with DistributedSegmentReadLocker. We found after a while of production usage that some Lucene files were randomly removed from the caches, but remained in the file listing entry, which resulted in an unusable index.
> We managed to replicate the problem in a test that acquires and releases read lock concurrently and checks for file deletion. We found this fails quickly when using REPL_SYNC mode, but runs for a while with DIST_SYNC.
> Some extra logging indicated that the replace command used to increment the lock counter across multiple cluster members, results in an single increment when called concurrently, with both calls reporting success. This eventually causes the file deletion, as we have now mis-counted the number of readers. We also observed the opposite effect of the counter only decrementing by one when releasing.
> Our conclusion is that the replace command fails atomicity when in REPL_SYNC mode, but works in other modes, we tried DIST_SYNC, DIST_ASYNC and REPL_ASYNC.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-6892) Endpoint schemas have several issues
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-6892?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-6892:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Alpha4
Resolution: Done
> Endpoint schemas have several issues
> ------------------------------------
>
> Key: ISPN-6892
> URL: https://issues.jboss.org/browse/ISPN-6892
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Server
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Alpha4
>
>
> The endpoint schemas have several issues:
> - the rest-connector doesn't specify the socket-binding and ignore-caches attributes
> - the await-initial-retrieval attribute is wrongly named await-initial-transfer
> - the sni element specifies a maxOccurs="1" instead of unlimited
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months