June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4450) RemoteStore uses wrong classloader with rawValues

by Dennis Reed (JIRA)

Dennis Reed created ISPN-4450: --------------------------------- Summary: RemoteStore uses wrong classloader with rawValues Key: ISPN-4450 URL: https://issues.jboss.org/browse/ISPN-4450 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Loaders and Stores Affects Versions: 6.0.2.Final Reporter: Dennis Reed Assignee: Dan Berindei RemoteStore uses the wrong classloader (Infinispan's classloader instead of the caller's classloader) during deserialization when rawValues=true is set. It uses a GenericJBossMarshaller, which is hard-coded to only look in Infinispan's classloader). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4449) Remove support for Apache Lucene 3 in the Lucene Directory

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4449?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-4449: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2676 > Remove support for Apache Lucene 3 in the Lucene Directory > ---------------------------------------------------------- > > Key: ISPN-4449 > URL: https://issues.jboss.org/browse/ISPN-4449 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > We support Apache Lucene versions >4 since a while now, we need to drop the older support to be able to finally take advantage of Lucene 4 specific features. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4449) Remove support for Apache Lucene 3 in the Lucene Directory

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4449: ------------------------------------- Summary: Remove support for Apache Lucene 3 in the Lucene Directory Key: ISPN-4449 URL: https://issues.jboss.org/browse/ISPN-4449 Project: Infinispan Issue Type: Task Security Level: Public (Everyone can see) Components: Lucene Directory Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 7.0.0.Alpha5 We support Apache Lucene versions >4 since a while now, we need to drop the older support to be able to finally take advantage of Lucene 4 specific features. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4449) Remove support for Apache Lucene 3 in the Lucene Directory

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4449?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-4449: ---------------------------------- Fix Version/s: 7.0.0.Final > Remove support for Apache Lucene 3 in the Lucene Directory > ---------------------------------------------------------- > > Key: ISPN-4449 > URL: https://issues.jboss.org/browse/ISPN-4449 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > We support Apache Lucene versions >4 since a while now, we need to drop the older support to be able to finally take advantage of Lucene 4 specific features. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1303) More FileCacheStore optimizations

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-1303?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-1303: --------------------------------------- [~rvansa] Reassigning to you to have a look, I think this can be marked as out of date? > More FileCacheStore optimizations > --------------------------------- > > Key: ISPN-1303 > URL: https://issues.jboss.org/browse/ISPN-1303 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Affects Versions: 5.0.0.CR8 > Reporter: Robert Stupp > Assignee: Radim Vansa > Attachments: CombinedBucketFileCacheStore.java > > > Still some more optimizations > 1. added a check to prohibit purge at all, if the whole cache store does not contain any expireable cache entry (works great with non-expireable cache entries - like Lucene indexes) > 2. added some more configuration options for purge: > 2.a. minimum time to wait between to purge runs > 2.b. minimum time to wait after last update to a bucket before purge run > 2.c. maximum time to wait after the last purge run > 3. prohibit purge run, if no update occured > 4. prohibit purge test (and execution), if bucket file did not change after last purge run > Will attach source code. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3503) Upstream server build doesn't include protobuf libraries in client/hotrod/java directory

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3503?page=com.atlassian.jira.plugin.... ] Sanne Grinovero resolved ISPN-3503. ----------------------------------- Resolution: Out of Date > Upstream server build doesn't include protobuf libraries in client/hotrod/java directory > ---------------------------------------------------------------------------------------- > > Key: ISPN-3503 > URL: https://issues.jboss.org/browse/ISPN-3503 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 6.0.0.Alpha4 > Reporter: Michal Linhard > Assignee: Tristan Tarrant > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/user/mlinhard@REDHAT.COM... > This is the contents of the client/hotrod/java folder: > {code} > adding: infinispan-server-6.0.x/client/hotrod/java/jboss-marshalling-river-1.3.15.GA.jar (deflated 8%) > adding: infinispan-server-6.0.x/client/hotrod/java/jboss-marshalling-1.3.15.GA.jar (deflated 12%) > adding: infinispan-server-6.0.x/client/hotrod/java/jboss-logging-3.1.1.GA.jar (deflated 10%) > adding: infinispan-server-6.0.x/client/hotrod/java/commons-pool-1.6.jar (deflated 8%) > adding: infinispan-server-6.0.x/client/hotrod/java/infinispan-commons-6.0.0-SNAPSHOT.jar (deflated 13%) > adding: infinispan-server-6.0.x/client/hotrod/java/infinispan-client-hotrod-6.0.0-SNAPSHOT.jar (deflated 12%) > {code} > JDG 6.2.0.DR4 doesn't have this problem, but this affects my regression testing where I use builds from latest upstream snapshots -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1303) More FileCacheStore optimizations

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-1303?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-1303: ---------------------------------- Assignee: Radim Vansa (was: Manik Surtani) > More FileCacheStore optimizations > --------------------------------- > > Key: ISPN-1303 > URL: https://issues.jboss.org/browse/ISPN-1303 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Affects Versions: 5.0.0.CR8 > Reporter: Robert Stupp > Assignee: Radim Vansa > Attachments: CombinedBucketFileCacheStore.java > > > Still some more optimizations > 1. added a check to prohibit purge at all, if the whole cache store does not contain any expireable cache entry (works great with non-expireable cache entries - like Lucene indexes) > 2. added some more configuration options for purge: > 2.a. minimum time to wait between to purge runs > 2.b. minimum time to wait after last update to a bucket before purge run > 2.c. maximum time to wait after the last purge run > 3. prohibit purge run, if no update occured > 4. prohibit purge test (and execution), if bucket file did not change after last purge run > Will attach source code. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4431) CLI codecs do set entry version in metadata

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4431?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4431: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 Resolution: Done > CLI codecs do set entry version in metadata > ------------------------------------------- > > Key: ISPN-4431 > URL: https://issues.jboss.org/browse/ISPN-4431 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 7.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha5 > > > When the CLI writes to the cache using one of the server codecs it must set a version, because the server protocol handlers expect to find it -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4424) getCacheEntry is not safe

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4424?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4424: ----------------------------------- Summary: getCacheEntry is not safe (was: ReplaceIfUnmodified is broken under concurrent execution) > getCacheEntry is not safe > ------------------------- > > Key: ISPN-4424 > URL: https://issues.jboss.org/browse/ISPN-4424 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test: > ``` > 2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463 > 2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464 > 2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464 > 2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465 > ``` > Here you see two threads applying the same replacement, from 463 to 464. > The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4424) getCacheEntry is not safe

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4424?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4424: ----------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/2671 > getCacheEntry is not safe > ------------------------- > > Key: ISPN-4424 > URL: https://issues.jboss.org/browse/ISPN-4424 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 6.0.2.Final, 7.0.0.Alpha4 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > Versioned update with a multi threaded Hot Rod client results in inconsistency. Some replaceWithVersion return true ignoring a version update executed in another thread. Here's a log excerpt of a concurrency stress test: > ``` > 2014-06-20 16:16:56,798 INFO [PutFromNull] (pool-7-thread-10) count=462,prev=462,new=463 > 2014-06-20 16:16:56,820 INFO [PutFromNull] (pool-7-thread-9) count=463,prev=463,new=464 > 2014-06-20 16:16:56,831 INFO [PutFromNull] (pool-7-thread-2) count=464,prev=463,new=464 > 2014-06-20 16:16:56,845 INFO [PutFromNull] (pool-7-thread-9) count=465,prev=464,new=465 > ``` > Here you see two threads applying the same replacement, from 463 to 464. > The issue appears a result of a race condition in Hot Rod server's protocol decoder. When replaceIfUmodified is received, the cache entry is retrieved to verify whether the version in the server and the version sent in the command match. However, the cache entry retrieved is mutable, and the value could change midway through this operation as a result of another thread updating the value. Please find below some log snippets showing this. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014