May 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7840) Indexing should happen on owners

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7840?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-7840: ----------------------------------------- To avoid having to remotely fetch the previous result, and allow commands to rely in the entries from the context, Index.LOCAL should be deprecated and mapped to Index.PRIMARY_OWNER, and Index.ALL should be done on all owners > Indexing should happen on owners > -------------------------------- > > Key: ISPN-7840 > URL: https://issues.jboss.org/browse/ISPN-7840 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Reporter: Gustavo Fernandes > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7840) Indexing should happen on owners

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7840?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7840: ------------------------------------ Summary: Indexing should happen on owners (was: Deprecate Index.LOCAL) > Indexing should happen on owners > -------------------------------- > > Key: ISPN-7840 > URL: https://issues.jboss.org/browse/ISPN-7840 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying > Reporter: Gustavo Fernandes > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7851) Error "newValue is null" while connecting to cache for Infinispan 9.0.0.Final

by Santosh Haranath (JIRA)

[ https://issues.jboss.org/browse/ISPN-7851?page=com.atlassian.jira.plugin.... ] Santosh Haranath updated ISPN-7851: ----------------------------------- Description: I configured cross-site replication using infinispan 9.0.0.CR3 and everything worked then upgraded it to 9.0.0.Final but same configuration failed to perform cross-site replication with the latest version. During debugging I observed the following error when trying to update cache default from ispn-cli(infinispan-server-9.0.0.Final/ispn-cli.sh FLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null I deployed a fresh Infinispan 9.0.0.Final without any customization in standalone mode but still got same error. > ./ispn-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect [standalone@localhost:9990 /] container local [standalone@localhost:9990 cache-container=local] cache default WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null [standalone@localhost:9990 cache-container=local] With a out of the box 9.0.0.CR3 deployment cache update worked fine > ./ispn-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect [standalone@localhost:9990 /] container local [standalone@localhost:9990 cache-container=local] cache default [standalone@localhost:9990 local-cache=default] put a a [standalone@localhost:9990 local-cache=default] get a a [standalone@localhost:9990 local-cache=default] See https://developer.jboss.org/message/971206#971206 was: I configured cross-site replication using infinispan 9.0.0.CR3 and everything worked then upgraded it to 9.0.0.Final but same configuration failed to perform cross-site replication with the latest version. During debugging I observed the following error when trying to update cache default from ispn-cli(infinispan-server-9.0.0.Final/ispn-cli.sh FLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null I deployed a fresh Infinispan 9.0.0.Final without any customization in standalone mode but still got same error. > ./ispn-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect [standalone@localhost:9990 /] container local [standalone@localhost:9990 cache-container=local] cache default WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null [standalone@localhost:9990 cache-container=local] With a out of the box 9.0.0.CR3 deployment cache update worked fine > ./ispn-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect [standalone@localhost:9990 /] container local [standalone@localhost:9990 cache-container=local] cache default [standalone@localhost:9990 local-cache=default] put a a [standalone@localhost:9990 local-cache=default] get a a [standalone@localhost:9990 local-cache=default] > Error "newValue is null" while connecting to cache for Infinispan 9.0.0.Final > ----------------------------------------------------------------------------- > > Key: ISPN-7851 > URL: https://issues.jboss.org/browse/ISPN-7851 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.Final > Reporter: Santosh Haranath > > I configured cross-site replication using infinispan 9.0.0.CR3 and everything worked then upgraded it to 9.0.0.Final but same configuration failed to perform cross-site replication with the latest version. > > During debugging I observed the following error when trying to update cache default from ispn-cli(infinispan-server-9.0.0.Final/ispn-cli.sh > > FLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null > > I deployed a fresh Infinispan 9.0.0.Final without any customization in standalone mode but still got same error. > > ./ispn-cli.sh > You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. > [disconnected /] connect > [standalone@localhost:9990 /] container local > [standalone@localhost:9990 cache-container=local] cache default > WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null > [standalone@localhost:9990 cache-container=local] > > With a out of the box 9.0.0.CR3 deployment cache update worked fine > > ./ispn-cli.sh > You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. > [disconnected /] connect > [standalone@localhost:9990 /] container local > [standalone@localhost:9990 cache-container=local] cache default > [standalone@localhost:9990 local-cache=default] put a a > [standalone@localhost:9990 local-cache=default] get a > a > [standalone@localhost:9990 local-cache=default] > See > https://developer.jboss.org/message/971206#971206 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7851) Error "newValue is null" while connecting to cache for Infinispan 9.0.0.Final

by Santosh Haranath (JIRA)

Santosh Haranath created ISPN-7851: -------------------------------------- Summary: Error "newValue is null" while connecting to cache for Infinispan 9.0.0.Final Key: ISPN-7851 URL: https://issues.jboss.org/browse/ISPN-7851 Project: Infinispan Issue Type: Bug Affects Versions: 9.0.0.Final Reporter: Santosh Haranath I configured cross-site replication using infinispan 9.0.0.CR3 and everything worked then upgraded it to 9.0.0.Final but same configuration failed to perform cross-site replication with the latest version. During debugging I observed the following error when trying to update cache default from ispn-cli(infinispan-server-9.0.0.Final/ispn-cli.sh FLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null I deployed a fresh Infinispan 9.0.0.Final without any customization in standalone mode but still got same error. > ./ispn-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect [standalone@localhost:9990 /] container local [standalone@localhost:9990 cache-container=local] cache default WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: newValue is null [standalone@localhost:9990 cache-container=local] With a out of the box 9.0.0.CR3 deployment cache update worked fine > ./ispn-cli.sh You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect [standalone@localhost:9990 /] container local [standalone@localhost:9990 cache-container=local] cache default [standalone@localhost:9990 local-cache=default] put a a [standalone@localhost:9990 local-cache=default] get a a [standalone@localhost:9990 local-cache=default] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5740) HotRod client write buffer is too large

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5740?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5740: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1448366|https://bugzilla.redhat.com/show_bug.cgi?id=1448366] from ASSIGNED to POST > HotRod client write buffer is too large > --------------------------------------- > > Key: ISPN-5740 > URL: https://issues.jboss.org/browse/ISPN-5740 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 8.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.1.0.Alpha1, 8.1.0.Final, 8.0.2.Final > > > The ISPN-1015 fix added a buffer to the HotRod client transport to reduce the number of syscalls. But that buffer's size is not fixed, instead it's based on {{Socket.getSendBufferSize()}}, which in turn is based on the kernel's {{net.core.wmem_max}}. > JGroups needs {{net.core.wmem_max}} greater or equal than {{UDP.ucast_send_buf_size}}, which is 1MB by default. That is probably too much for the {{TcpTransport}}'s buffer, because the buffer is also duplicated in the OS. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7802) Use chunked reads/writes in TcpTransport

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-7802?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-7802: ----------------------------------------------- Dan Berindei <dberinde(a)redhat.com> changed the Status of [bug 1448366|https://bugzilla.redhat.com/show_bug.cgi?id=1448366] from ASSIGNED to POST > Use chunked reads/writes 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. > EDIT: As Tristan pointed out, the {{BufferedInputStream}} does not grow in our use case, but if {{TcpTransport}} passes a big {{byte[]}} buffer, the implementation works as read through/write through. Therefore we need to chunk all calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3795: --------------------------------------- Awesome! > QueryInterceptor incorrectly relies on the return value of a RemoveCommand > -------------------------------------------------------------------------- > > Key: ISPN-3795 > URL: https://issues.jboss.org/browse/ISPN-3795 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Fix For: 9.1.0.Final, 9.0.1.Final, 9.1.0.Alpha1 > > > QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index. > But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index. > QueryInterceptor should probably use the previous value from the context entries to update the index instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3795: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master and 9.0.x branch. Thanks [~gustavonalle]! > QueryInterceptor incorrectly relies on the return value of a RemoveCommand > -------------------------------------------------------------------------- > > Key: ISPN-3795 > URL: https://issues.jboss.org/browse/ISPN-3795 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Fix For: 9.1.0.Final, 9.0.1.Final, 9.1.0.Alpha1 > > > QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index. > But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index. > QueryInterceptor should probably use the previous value from the context entries to update the index instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3795: -------------------------------- Fix Version/s: 9.0.1.Final > QueryInterceptor incorrectly relies on the return value of a RemoveCommand > -------------------------------------------------------------------------- > > Key: ISPN-3795 > URL: https://issues.jboss.org/browse/ISPN-3795 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Fix For: 9.1.0.Final, 9.0.1.Final, 9.1.0.Alpha1 > > > QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index. > But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index. > QueryInterceptor should probably use the previous value from the context entries to update the index instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3795: -------------------------------- Fix Version/s: 9.1.0.Final 9.1.0.Alpha1 > QueryInterceptor incorrectly relies on the return value of a RemoveCommand > -------------------------------------------------------------------------- > > Key: ISPN-3795 > URL: https://issues.jboss.org/browse/ISPN-3795 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Gustavo Fernandes > Fix For: 9.1.0.Final, 9.1.0.Alpha1 > > > QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index. > But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index. > QueryInterceptor should probably use the previous value from the context entries to update the index instead. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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