[JBoss JIRA] (ISPN-5011) CacheManager not stopping when search factory not initialized
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5011?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5011:
------------------------------------
Description:
The situation can be reproduced in a simple test:
{code}
@Test
public void testStartAndStopWithoutIndexing() {
EmbeddedCacheManager cacheManager = ... // With indexing enabled, using infinispan directory
cacheManager.getCache();
cacheManager.stop();
assertEquals(ComponentStatus.TERMINATED, cacheManager.getStatus());
}
{code}
The issue is that query related caches are lazily created, and the stop( ) method fails with NPE
was:
The situation can be reproduced in a simple test:
{code}
@Test
public void testStartAndStopWithoutIndexing() {
EmbeddedCacheManager cacheManager = ... // With indexing enabled, using infinispan directory
cacheManager.getCache();
cacheManager.stop();
assertEquals(ComponentStatus.TERMINATED, cacheManager.getStatus());
}
{code}
The issue is that query related caches are not started, and the stop() method fails with NPE
> CacheManager not stopping when search factory not initialized
> -------------------------------------------------------------
>
> Key: ISPN-5011
> URL: https://issues.jboss.org/browse/ISPN-5011
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
>
> The situation can be reproduced in a simple test:
> {code}
> @Test
> public void testStartAndStopWithoutIndexing() {
> EmbeddedCacheManager cacheManager = ... // With indexing enabled, using infinispan directory
> cacheManager.getCache();
> cacheManager.stop();
> assertEquals(ComponentStatus.TERMINATED, cacheManager.getStatus());
> }
> {code}
> The issue is that query related caches are lazily created, and the stop( ) method fails with NPE
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5013) Server-side scripting using JSR-223 (javax.script)
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-5013:
-------------------------------------
Summary: Server-side scripting using JSR-223 (javax.script)
Key: ISPN-5013
URL: https://issues.jboss.org/browse/ISPN-5013
Project: Infinispan
Issue Type: Feature Request
Components: Core, Server
Affects Versions: 7.0.2.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 7.1.0.Final
Implement a scripting manager which stores custom scripts in a dedicated cache. These scripts will be invoked with a user-specified binding (i.e. a set of named parameters).
This component should support all known "code" extension points: simple, tasks, distexec, map/reduce, listeners, etc.
The script type should be supported by the available JSR-223 scripting engines
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5012) ClusterRegistry as a service cache provider
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-5012:
-------------------------------------
Summary: ClusterRegistry as a service cache provider
Key: ISPN-5012
URL: https://issues.jboss.org/browse/ISPN-5012
Project: Infinispan
Issue Type: Feature Request
Components: Core
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 7.1.0.Final
The ClusterRegistry is currently a volatile, replicated cache with a composite key and it does not serve the original purpose for which it was built. It should be refactored to be a service cache factory with a builder API based on desired features and a NamingStrategy so that we can have "well-known" caches as well as temporary caches. It should also be possible to use the cache dependency mechanism to "chain" service cache lifecycles to other caches.
Here's an example API (not a real example):
RegistryBuilder builder = registry.getBuilder();
builder.persistent().clustered().dependsOn(Cache<?,?> cache).namingStrategy(new StaticCacheNamingStrategy("___protobuf_metadata"))
This registry would be able to provide caches to the following use cases:
- protobuf schemas
- hotrod topology
- security acl
- map/reduce work caches
- index caches
- etc.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5011) CacheManager not stopping when search factory not initialized
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5011?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5011:
------------------------------------
Summary: CacheManager not stopping when search factory not initialized (was: CacheManager not stopping when search factory initialized)
> CacheManager not stopping when search factory not initialized
> -------------------------------------------------------------
>
> Key: ISPN-5011
> URL: https://issues.jboss.org/browse/ISPN-5011
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
>
> The situation can be reproduced in a simple test:
> {code}
> @Test
> public void testStartAndStopWithoutIndexing() {
> EmbeddedCacheManager cacheManager = ... // With indexing enabled, using infinispan directory
> cacheManager.getCache();
> cacheManager.stop();
> assertEquals(ComponentStatus.TERMINATED, cacheManager.getStatus());
> }
> {code}
> The issue is that query related caches are not started, and the stop() method fails with NPE
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-5011) CacheManager not stopping when search factory initialized
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-5011:
---------------------------------------
Summary: CacheManager not stopping when search factory initialized
Key: ISPN-5011
URL: https://issues.jboss.org/browse/ISPN-5011
Project: Infinispan
Issue Type: Bug
Reporter: Gustavo Fernandes
The situation can be reproduced in a simple test:
{code}
@Test
public void testStartAndStopWithoutIndexing() {
EmbeddedCacheManager cacheManager = ... // With indexing enabled, using infinispan directory
cacheManager.getCache();
cacheManager.stop();
assertEquals(ComponentStatus.TERMINATED, cacheManager.getStatus());
}
{code}
The issue is that query related caches are not started, and the stop() method fails with NPE
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-3811) Initial ST leaves node as member without data after MERGE
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3811?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3811:
------------------------------------
JGRP-1899 partly solves the issue, so nodes joining the cluster with a MERGE should be much rarer now.
> Initial ST leaves node as member without data after MERGE
> ---------------------------------------------------------
>
> Key: ISPN-3811
> URL: https://issues.jboss.org/browse/ISPN-3811
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Priority: Blocker
> Labels: testsuite_stability
>
> Under certain circumstances, JGroups can issue a MERGE view when a node is joining the cache. The new node joins the cluster, and all nodes have the same cache topology (not containing the joiner yet).
> During the merge, the CH's are joined (through CHFactory.union) and as all report the same topology/hash, the resulting hash is identical. However, the joiner is added to the members list and therefore it can finish the initial state transfer, although no data have been assigned to him.
> Later, the coordinator starts rebalance and the node begins to receive some data, but the thread which started the cluster manager (and should wait until the cluster becomes properly replicated through initial ST) is already released.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months