May 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7806) QueryInterceptor should not load entries from DC but context

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7806?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7806: ------------------------------ Description: Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect. As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor and CacheLoaderInterceptor (before xDistributionInterceptor), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value. There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well. was: Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect. Therefore we should move QueryInterceptor after EntryWrappingInterceptor and CacheLoaderInterceptor (before xDistributionInterceptor), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value. There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well. > QueryInterceptor should not load entries from DC but context > ------------------------------------------------------------ > > Key: ISPN-7806 > URL: https://issues.jboss.org/browse/ISPN-7806 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Adrian Nistor > > Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect. > As the data is not loaded (from DC/persistence) at current QI position, we should move QueryInterceptor after EntryWrappingInterceptor and CacheLoaderInterceptor (before xDistributionInterceptor), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value. > There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7806) QueryInterceptor should not load entries from DC but context

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7806: --------------------------------- Summary: QueryInterceptor should not load entries from DC but context Key: ISPN-7806 URL: https://issues.jboss.org/browse/ISPN-7806 Project: Infinispan Issue Type: Bug Components: Embedded Querying Affects Versions: 9.0.0.Final Reporter: Radim Vansa Assignee: Adrian Nistor Currently in {{visitPrepareCommand}} the query interceptor is loading data directly from data container. That's wrong - if the entry is passivated/evicted, the previous value is incorrect. Therefore we should move QueryInterceptor after EntryWrappingInterceptor and CacheLoaderInterceptor (before xDistributionInterceptor), and load the previous entry from context instead. The same approach should be taken for non-tx command, rather than relying on their return value. There will still be issues if the command has SKIP_CACHE_LOAD flag: I suggest warning message if it doesn't have SKIP_INDEXING flag as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7803) Functional commands-based AtomicMap

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7803?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7803: ------------------------------ Labels: atomic_map (was: ) > Functional commands-based AtomicMap > ----------------------------------- > > Key: ISPN-7803 > URL: https://issues.jboss.org/browse/ISPN-7803 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Radim Vansa > Assignee: Radim Vansa > Labels: atomic_map > > Implement AtomicMap based on the functional commands instead of DeltaAware. > * Fine-grained and coarse-grained locking options should be preserved, though it might be necessary to introduce further locking to achieve atomicity during command execution. > * Support transactional caches. > * This implementation should replace the original implementation (temporarily allowing to opt-in for the old variant with a system property). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7802) Use non-growing buffered input stream in TcpTransport

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7802?page=com.atlassian.jira.plugin.... ] Tristan Tarrant edited comment on ISPN-7802 at 5/5/17 8:50 AM: --------------------------------------------------------------- This might not be necessary if mark isn't used (and it doesn't look like it). was (Author: nadirx): This might not be necessary if mark isn't use (and it doesn't look like it). > Use non-growing buffered input stream in TcpTransport > ----------------------------------------------------- > > Key: ISPN-7802 > URL: https://issues.jboss.org/browse/ISPN-7802 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Tristan Tarrant > > The buffering implementation of {{TcpTransport.socketInputStream}} needs to use fixed size input buffer, rather than growing as {{BufferedInputStream}} does. Growing buffer can lead to excessive memory consumption on heap, and more importantly, by direct memory allocated in JDK classes and pooled in thread-local caches. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7652) Incorrect River marshaller in server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7652?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7652: ---------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5121, https://github.com/infinispan/infinispan/pull/5122, https://github.com/infinispan/infinispan/pull/5123 (was: https://github.com/infinispan/infinispan/pull/5121, https://github.com/infinispan/infinispan/pull/5122) > Incorrect River marshaller in server > ------------------------------------ > > Key: ISPN-7652 > URL: https://issues.jboss.org/browse/ISPN-7652 > Project: Infinispan > Issue Type: Task > Components: Marshalling, Server > Affects Versions: 8.2.6.Final, 9.0.0.CR3 > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 9.0.0.CR4, 8.2.7.Final, 9.1.0.Alpha1 > > > After upgrading JBoss Marshalling to 2.0.0.Beta3, we forgot to apply similar changes to force JBoss Marshaller's River to be in sync. As a result, the server currently ships River 1.4.10 version which causes issues mentioned [here|https://github.com/infinispan/infinispan/pull/4709] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7805) Use non-growing buffered input stream in TcpTransport

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-7805: -------------------------------------- Summary: Use non-growing buffered input stream in TcpTransport Key: ISPN-7805 URL: https://issues.jboss.org/browse/ISPN-7805 Project: Infinispan Issue Type: Bug Components: Remote Protocols Affects Versions: 9.0.0.Final Reporter: Wolf-Dieter Fink Assignee: Tristan Tarrant The buffering implementation of {{TcpTransport.socketInputStream}} needs to use fixed size input buffer, rather than growing as {{BufferedInputStream}} does. Growing buffer can lead to excessive memory consumption on heap, and more importantly, by direct memory allocated in JDK classes and pooled in thread-local caches. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7802) Use non-growing buffered input stream in TcpTransport

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-7802?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-7802: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1448441 Bugzilla Update: Perform > Use non-growing buffered input stream in TcpTransport > ----------------------------------------------------- > > Key: ISPN-7802 > URL: https://issues.jboss.org/browse/ISPN-7802 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.Final > Reporter: Radim Vansa > Assignee: Tristan Tarrant > > The buffering implementation of {{TcpTransport.socketInputStream}} needs to use fixed size input buffer, rather than growing as {{BufferedInputStream}} does. Growing buffer can lead to excessive memory consumption on heap, and more importantly, by direct memory allocated in JDK classes and pooled in thread-local caches. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7652) Incorrect River marshaller in server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7652?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7652: ---------------------------------- Fix Version/s: 9.1.0.Alpha1 > Incorrect River marshaller in server > ------------------------------------ > > Key: ISPN-7652 > URL: https://issues.jboss.org/browse/ISPN-7652 > Project: Infinispan > Issue Type: Task > Components: Marshalling, Server > Affects Versions: 8.2.6.Final, 9.0.0.CR3 > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 9.0.0.CR4, 8.2.7.Final, 9.1.0.Alpha1 > > > After upgrading JBoss Marshalling to 2.0.0.Beta3, we forgot to apply similar changes to force JBoss Marshaller's River to be in sync. As a result, the server currently ships River 1.4.10 version which causes issues mentioned [here|https://github.com/infinispan/infinispan/pull/4709] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7652) Incorrect River marshaller in server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7652?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7652: ---------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/5121, https://github.com/infinispan/infinispan/pull/5122 (was: https://github.com/infinispan/infinispan/pull/5121) > Incorrect River marshaller in server > ------------------------------------ > > Key: ISPN-7652 > URL: https://issues.jboss.org/browse/ISPN-7652 > Project: Infinispan > Issue Type: Task > Components: Marshalling, Server > Affects Versions: 8.2.6.Final, 9.0.0.CR3 > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 9.0.0.CR4, 8.2.7.Final > > > After upgrading JBoss Marshalling to 2.0.0.Beta3, we forgot to apply similar changes to force JBoss Marshaller's River to be in sync. As a result, the server currently ships River 1.4.10 version which causes issues mentioned [here|https://github.com/infinispan/infinispan/pull/4709] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7652) Incorrect River marshaller in server

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7652?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7652: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5121 > Incorrect River marshaller in server > ------------------------------------ > > Key: ISPN-7652 > URL: https://issues.jboss.org/browse/ISPN-7652 > Project: Infinispan > Issue Type: Task > Components: Marshalling, Server > Affects Versions: 8.2.6.Final, 9.0.0.CR3 > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 9.0.0.CR4, 8.2.7.Final > > > After upgrading JBoss Marshalling to 2.0.0.Beta3, we forgot to apply similar changes to force JBoss Marshaller's River to be in sync. As a result, the server currently ships River 1.4.10 version which causes issues mentioned [here|https://github.com/infinispan/infinispan/pull/4709] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 May 2017