September 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9453) Document FORCE_WRITE_LOCK not working in non-tx caches

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9453?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-9453: ------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Document FORCE_WRITE_LOCK not working in non-tx caches > ------------------------------------------------------ > > Key: ISPN-9453 > URL: https://issues.jboss.org/browse/ISPN-9453 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 9.3.1.Final > Reporter: Radim Vansa > Assignee: Don Naro > Fix For: 9.4.0.Final > > > The user guide mentions {{Flag.FORCE_WRITE_LOCK}} in the context of pessimistic transactions but it does not say what this does in non-transactional caches. > In non-tx cache it does not work since when on backup owner, the {{get()}} just reads the value. It does not go to primary to lock there. When on non-owner, it reads from some other owner but not necessarily from the primary. The flag does not force the command to acquire locks remotely. > To put it in other words, it works only scarcely = it does not work. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9500) ConcurrentSmallIntSet.clear() does not always set the size to 0

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9500?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9500: ------------------------------- Status: Open (was: New) > ConcurrentSmallIntSet.clear() does not always set the size to 0 > --------------------------------------------------------------- > > Key: ISPN-9500 > URL: https://issues.jboss.org/browse/ISPN-9500 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.4.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > {{ConcurrentSmallIntSet.clear()}} processes the array values with a loop that stops when {{value <= 0}}. This breaks when the highest bit is set, leaving the set empty but with {{size() > 0}} and {{isEmpty() == false}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9500) ConcurrentSmallIntSet.clear() does not always set the size to 0

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9500: ---------------------------------- Summary: ConcurrentSmallIntSet.clear() does not always set the size to 0 Key: ISPN-9500 URL: https://issues.jboss.org/browse/ISPN-9500 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.4.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.4.0.Final {{ConcurrentSmallIntSet.clear()}} processes the array values with a loop that stops when {{value <= 0}}. This breaks when the highest bit is set, leaving the set empty but with {{size() > 0}} and {{isEmpty() == false}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HRJS-72) Switch to Node.js platform Promise module

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-72?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño reassigned HRJS-72: ------------------------------------ Assignee: Galder Zamarreño > Switch to Node.js platform Promise module > ----------------------------------------- > > Key: HRJS-72 > URL: https://issues.jboss.org/browse/HRJS-72 > Project: Infinispan Javascript client > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HRJS-73) Update dependencies

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-73?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño reassigned HRJS-73: ------------------------------------ Assignee: Galder Zamarreño > Update dependencies > ------------------- > > Key: HRJS-73 > URL: https://issues.jboss.org/browse/HRJS-73 > Project: Infinispan Javascript client > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 0.6.0 > > > Production: log4js, undescore > Test: request, jasmine-node -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9415) Client topology is not updated after cache becomes degraded

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9415?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9415: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Client topology is not updated after cache becomes degraded > ----------------------------------------------------------- > > Key: ISPN-9415 > URL: https://issues.jboss.org/browse/ISPN-9415 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 9.4.0.Beta1, 9.3.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > When a new server is started, or after a merge, the other servers may see it as a an owner in the consistent hash before the other servers see its server address in the address cache ({{___hotRodTopologyCache}}). When a server needs to send a topology update but some of the servers are missing from the address cache, it can't send the topology update, so it tries to send a "partial update" that excludes the missing servers from the segment owners. In order to send the full topology update when the address cache is populated, the partial topology update has to be sent a smaller topology id, and that means it is only send if {{serverTopologyId >= clientTopologyId + 2}}. > When the cluster splits and the cache becomes degraded, the servers in the other partition are removed from the address cache, but the list of segment owners is not updated, and the topology id is only incremented by 1. The address cache is incomplete, but a partial update cannot be sent, so the client keeps the old topology and keeps trying to connect to the servers in the other partition. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9067) Tests should set the node name even for non-clustered cache manager

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9067?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9067: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.4.0.Final (was: 9.3.0.CR1) Resolution: Done > Tests should set the node name even for non-clustered cache manager > ------------------------------------------------------------------- > > Key: ISPN-9067 > URL: https://issues.jboss.org/browse/ISPN-9067 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > The node name is included in the thread name by all the internal executors, but non-clustered cache managers don't have a node name, and that makes it harder to filter log messages for a particular test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9332) REPL local iteration optimization cannot be used when store has write behind

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9332?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-9332: ------------------------------------ Isn't the idea that clear will always create a new State? > REPL local iteration optimization cannot be used when store has write behind > ---------------------------------------------------------------------------- > > Key: ISPN-9332 > URL: https://issues.jboss.org/browse/ISPN-9332 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Streams > Affects Versions: 9.3.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.Final > > > When write behind is enabled, the write modification is stored on the primary owner. REPL local iteration can read from non owned data, thus causing an inconsistency. > Thus distributed streams should always go remote when not all segments are primarily owned on a given node when write behind is enabled. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9499) Json to text conversion ignore charset

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-9499: --------------------------------------- Summary: Json to text conversion ignore charset Key: ISPN-9499 URL: https://issues.jboss.org/browse/ISPN-9499 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 9.4.0.CR2 Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes Fix For: 9.4.0.Final A cache configured with application/json does not convert properly text/plain content in different charsets -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9498) Index filesystem paths in server should point to data directory

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-9498?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-9498: ----------------------------------------- I was thinking in making the default configuration (when using auto-config=true and this results in disk storage) relative to the data/ folder. But the user should be free to choose another folder outside the data/ path if he wants. Does the file-store/rocksbd store "force" the storage to be under data/ ? > Index filesystem paths in server should point to data directory > --------------------------------------------------------------- > > Key: ISPN-9498 > URL: https://issues.jboss.org/browse/ISPN-9498 > Project: Infinispan > Issue Type: Bug > Components: Indexing, Server > Affects Versions: 9.4.0.CR1, 9.3.3.Final > Reporter: Galder Zamarreño > Assignee: Gustavo Fernandes > > Certain indexing configurations result in using filesystem as index storage. > When running such configurations in a server environment, filesystem path should be somewhere within the server's data directory. This is the natural place for such data. > When running in OpenShift, server's data folder can be backed by a persistent volume. This means that the fileystem volume survives after restarts. > Plugging server's data directory is already happening for [file-store|https://github.com/infinispan/infinispan/blob/master/server/in...] and [rocksdb-store|https://github.com/infinispan/infinispan/blob/master/server...]. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 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 September 2018