April 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5380) Create a registry of internal caches

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5380?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5380: ---------------------------------- Fix Version/s: 7.2.0.Final > Create a registry of internal caches > ------------------------------------ > > Key: ISPN-5380 > URL: https://issues.jboss.org/browse/ISPN-5380 > Project: Infinispan > Issue Type: Task > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > > Several parts of the code create caches for internal use (hotrod topology, protobuf schema, scripting cache, recovery, etc). These should all be created through a common interface so that thet can be filtered out when necessary. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5380) Create a registry of internal caches

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5380?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5380: ---------------------------------- Component/s: Core > Create a registry of internal caches > ------------------------------------ > > Key: ISPN-5380 > URL: https://issues.jboss.org/browse/ISPN-5380 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Final > > > Several parts of the code create caches for internal use (hotrod topology, protobuf schema, scripting cache, recovery, etc). These should all be created through a common interface so that thet can be filtered out when necessary. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5240) CacheContainer cluster statistics count in entries in internal hotrodTopologyCache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5240?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-5240: ------------------------------------- Assignee: Tristan Tarrant > CacheContainer cluster statistics count in entries in internal hotrodTopologyCache > ---------------------------------------------------------------------------------- > > Key: ISPN-5240 > URL: https://issues.jboss.org/browse/ISPN-5240 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 7.1.0.Final > Reporter: Martin Gencur > Assignee: Tristan Tarrant > > Example: When I start fresh new instance of Infinispan server and see numberOfEntries, I get result=1. But this is only true when HotRod endpoint is started, otherwise it returns correct result=0. > I think these cluster-wise statistics should not count entries in internal caches. They should only count "real" data. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5240) CacheContainer cluster statistics count in entries in internal hotrodTopologyCache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5240?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5240: ---------------------------------- Status: Open (was: New) > CacheContainer cluster statistics count in entries in internal hotrodTopologyCache > ---------------------------------------------------------------------------------- > > Key: ISPN-5240 > URL: https://issues.jboss.org/browse/ISPN-5240 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 7.1.0.Final > Reporter: Martin Gencur > Assignee: Tristan Tarrant > > Example: When I start fresh new instance of Infinispan server and see numberOfEntries, I get result=1. But this is only true when HotRod endpoint is started, otherwise it returns correct result=0. > I think these cluster-wise statistics should not count entries in internal caches. They should only count "real" data. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5240) CacheContainer cluster statistics count in entries in internal hotrodTopologyCache

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5240?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5240: ---------------------------------- Summary: CacheContainer cluster statistics count in entries in internal hotrodTopologyCache (was: CacheContainer cluster statistics count in entries in internal hotrodTolologyCache) > CacheContainer cluster statistics count in entries in internal hotrodTopologyCache > ---------------------------------------------------------------------------------- > > Key: ISPN-5240 > URL: https://issues.jboss.org/browse/ISPN-5240 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 7.1.0.Final > Reporter: Martin Gencur > > Example: When I start fresh new instance of Infinispan server and see numberOfEntries, I get result=1. But this is only true when HotRod endpoint is started, otherwise it returns correct result=0. > I think these cluster-wise statistics should not count entries in internal caches. They should only count "real" data. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5379?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5379: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1212505 > Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-5379 > URL: https://issues.jboss.org/browse/ISPN-5379 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.Final > > > From Dennis Reed: > A ConcurrentModificationException in the CacheWriter interceptor during a commit. > java.util.ConcurrentModificationException > at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953) > at java.util.LinkedList$ListItr.next(LinkedList.java:886) > at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210) > at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) > The code is looping through the modifications associated with the transaction: > List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications(); > ... > 210: for (WriteCommand cacheCommand : modifications) { > The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer". > But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification? > Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5379?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5379: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1212505|https://bugzilla.redhat.com/show_bug.cgi?id=1212505] from NEW to ASSIGNED > Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-5379 > URL: https://issues.jboss.org/browse/ISPN-5379 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.2.0.Final > > > From Dennis Reed: > A ConcurrentModificationException in the CacheWriter interceptor during a commit. > java.util.ConcurrentModificationException > at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953) > at java.util.LinkedList$ListItr.next(LinkedList.java:886) > at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210) > at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) > The code is looping through the modifications associated with the transaction: > List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications(); > ... > 210: for (WriteCommand cacheCommand : modifications) { > The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer". > But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification? > Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5379) Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache

by Dan Berindei (JIRA)

Dan Berindei created ISPN-5379: ---------------------------------- Summary: Persistence with stringKeyedJdbcStore throwing ConcurrentModificationException while adding data to cache Key: ISPN-5379 URL: https://issues.jboss.org/browse/ISPN-5379 Project: Infinispan Issue Type: Bug Components: Core, Loaders and Stores Affects Versions: 6.0.2.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.2.0.Final >From Dennis Reed: A ConcurrentModificationException in the CacheWriter interceptor during a commit. java.util.ConcurrentModificationException at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:953) at java.util.LinkedList$ListItr.next(LinkedList.java:886) at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:210) at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) The code is looping through the modifications associated with the transaction: List<WriteCommand> modifications = ctx.getCacheTransaction().getAllModifications(); ... 210: for (WriteCommand cacheCommand : modifications) { The transaction's modification list is stored as a synchronized list with a comment "we need to synchronize this collection to be able to get a valid snapshot from another thread during state transfer". But this thread is not doing state transfer, and I'd assume "get a valid snapshot" wouldn't include modification? Is it valid for this list to be modified from another thread (in which case all iterations should be synchronized), or is something modifying it incorrectly? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5085) Convert REST server to using RESTEasy's Netty container integration

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5085?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5085: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3375 > Convert REST server to using RESTEasy's Netty container integration > ------------------------------------------------------------------- > > Key: ISPN-5085 > URL: https://issues.jboss.org/browse/ISPN-5085 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.2.0.CR1, 7.2.0.Final > > > REST server is currently based on RESTEasy which relies on having a web container underneath to do its job. So, we're depending on jbossweb/undertow to provide the container capabilities. Instead, we should switch to a Netty based container to better control our dependencies. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5085) Convert REST server to using RESTEasy's Netty container integration

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-5085?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-5085: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Convert REST server to using RESTEasy's Netty container integration > ------------------------------------------------------------------- > > Key: ISPN-5085 > URL: https://issues.jboss.org/browse/ISPN-5085 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.2.0.CR1, 7.2.0.Final > > > REST server is currently based on RESTEasy which relies on having a web container underneath to do its job. So, we're depending on jbossweb/undertow to provide the container capabilities. Instead, we should switch to a Netty based container to better control our dependencies. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2015