[JBoss JIRA] (ISPN-6460) Race condition during server start causes wrong configuration to be used for cache 'default'
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-6460:
---------------------------------------
Summary: Race condition during server start causes wrong configuration to be used for cache 'default'
Key: ISPN-6460
URL: https://issues.jboss.org/browse/ISPN-6460
Project: Infinispan
Issue Type: Bug
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
The rest endpoint subsystem forces the startup of the "default" cache, whose configuration might not yet be read from the server xml and defined in the cache manager.
As a result, the "default" cache will be started with a LOCAL configuration, and will never use the right configuration again. This can cause side effects such as the cache topology is not sent during a PingRequest (since cache is configured as LOCAL), also potentially ClearCommand failing with NPE since the default cache configuration is LOCAL in one node and clustered on another.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (ISPN-6459) NPE on cache.getCacheTopologyInfo
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6459?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6459:
------------------------------------
Steps to Reproduce:
The error happen sometimes in this PR: https://github.com/infinispan/infinispan-hadoop/pull/6 when running on Travis. It's possible to reproduce locally by pinning the execution to a single CPU, running on a loop:
{noformat}
taskset -c 0 mvn clean install -Dtest=FailoverHandlingTest#testReadFromInfinispanSaveToHDFS_StopPreferedServer
{noformat}
was:
The error happen sometimes in this PR: https://github.com/infinispan/infinispan-hadoop/pull/6
when running on Travis. It's possible to reproduce locally by pinning the execution to a single CPU, running on a loop
{noformat}
taskset -c 0 mvn clean install -Dtest=FailoverHandlingTest#testReadFromInfinispanSaveToHDFS_StopPreferedServer
{noformat}
> NPE on cache.getCacheTopologyInfo
> ---------------------------------
>
> Key: ISPN-6459
> URL: https://issues.jboss.org/browse/ISPN-6459
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> Sometimes {{cache.getTopologyInfo}} fails with:
> {noformat}
> java.lang.NullPointerException: null
> at org.infinispan.client.hotrod.impl.CacheTopologyInfoImpl.getNumSegments(CacheTopologyInfoImpl.java:26)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (ISPN-6459) NPE on cache.getCacheTopologyInfo
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-6459:
---------------------------------------
Summary: NPE on cache.getCacheTopologyInfo
Key: ISPN-6459
URL: https://issues.jboss.org/browse/ISPN-6459
Project: Infinispan
Issue Type: Bug
Components: Server
Reporter: Gustavo Fernandes
Sometimes {{cache.getTopologyInfo}} fails with:
{noformat}
java.lang.NullPointerException: null
at org.infinispan.client.hotrod.impl.CacheTopologyInfoImpl.getNumSegments(CacheTopologyInfoImpl.java:26)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (ISPN-5557) Core threading redesign
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5557?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-5557:
----------------------------------
Status: Open (was: New)
> Core threading redesign
> -----------------------
>
> Key: ISPN-5557
> URL: https://issues.jboss.org/browse/ISPN-5557
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 7.2.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 9.0.0.Alpha1
>
>
> Infinispan needs a lot of threads, because everything is synchronous: locking, remote command invocations, cache writers. This causes various issues, from general context switching overhead to the thread pools getting full and causing deadlocks.
> We should redesign the core so that most blocking happens on the application threads, and the number of internal threads is kept to a minimum.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months