July 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8019) Upgrade to JGroups 4.0.4.Final

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8019?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8019: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to JGroups 4.0.4.Final > ------------------------------ > > Key: ISPN-8019 > URL: https://issues.jboss.org/browse/ISPN-8019 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 9.1.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.1.0.Final, 9.1.0.CR2 > > > Fixed issues: https://issues.jboss.org/projects/JGRP/versions/12334674 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8019) Upgrade to JGroups 4.0.4.Final

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8019?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8019: ------------------------------- Status: Open (was: New) > Upgrade to JGroups 4.0.4.Final > ------------------------------ > > Key: ISPN-8019 > URL: https://issues.jboss.org/browse/ISPN-8019 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 9.1.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.1.0.Final, 9.1.0.CR2 > > > Fixed issues: https://issues.jboss.org/projects/JGRP/versions/12334674 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8019) Upgrade to JGroups 4.0.4.Final

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8019?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8019: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5250 > Upgrade to JGroups 4.0.4.Final > ------------------------------ > > Key: ISPN-8019 > URL: https://issues.jboss.org/browse/ISPN-8019 > Project: Infinispan > Issue Type: Component Upgrade > Components: Core > Affects Versions: 9.1.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.1.0.Final, 9.1.0.CR2 > > > Fixed issues: https://issues.jboss.org/projects/JGRP/versions/12334674 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8019) Upgrade to JGroups 4.0.4.Final

by Dan Berindei (JIRA)

Dan Berindei created ISPN-8019: ---------------------------------- Summary: Upgrade to JGroups 4.0.4.Final Key: ISPN-8019 URL: https://issues.jboss.org/browse/ISPN-8019 Project: Infinispan Issue Type: Component Upgrade Components: Core Affects Versions: 9.1.0.CR1 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.1.0.Final, 9.1.0.CR2 Fixed issues: https://issues.jboss.org/projects/JGRP/versions/12334674 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7990) Provide a way to remove an entry from all indexes

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7990?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-7990: ----------------------------------------- bq. Incidentally you remind me of the terrible hack that Infinispan Query does to encode keys One thing at a time :) bq. I was merely concerned about the reliability (especially over time and in exceptional cases) of QueryKnownClasses I see. This class boils down to a REPL_SYNC cache (it uses Infinispan internal caches facility) but I can see it is *NOT* persistent, differently from the cache that stores protobuf. If we make it persistent, I think the reliability would be acceptable to work in "autodetection mode": we don't expect to remove from all indexes often, but very rarely. > Provide a way to remove an entry from all indexes > ------------------------------------------------- > > Key: ISPN-7990 > URL: https://issues.jboss.org/browse/ISPN-7990 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 9.1.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > This may be needed in some non frequent scenarios (happening during topology changes) where a write command cannot obtain the previous value to remove it from the index. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8008) Add Fault-tolerance to write-behind stores

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8008?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-8008: ------------------------------------ Option 2 might work if the cache is not bounded, but when it is bounded it doesn't make sense to keep a potentially unlimited number of entries with errors in memory. Also, it sounds very similar to option 1 with a huge {{modificationQueueSize}}. > Add Fault-tolerance to write-behind stores > ------------------------------------------ > > Key: ISPN-8008 > URL: https://issues.jboss.org/browse/ISPN-8008 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. > We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. > To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options: > * Attempt a write and catch an exception if the store is not currently available > * Add a method to return the current status of a store to the CacheWriter interface -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7990) Provide a way to remove an entry from all indexes

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-7990?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-7990: --------------------------------------- bq. And in Infinispan, we have the advantage of having unique document ids across all indices (it derives from the cache key). When you mention "unsafe", is it some internal limitation of the Hibernate Search engine, or the QueryKnownClasses (which is backed by a SYNC REPL cache) itself? No I'm not referring to some obscure limitation in Hibernate Search. I was merely concerned about the reliability (especially over time and in exceptional cases) of {{QueryKnownClasses}}, but since Adrian clarified this is finally being taken care of I guess I have no more concerns. Incidentally you remind me of the terrible hack that Infinispan Query does to encode keys. We should see if we can improve on that, especially after we've dropped "auto-discovery" of index mapping. > Provide a way to remove an entry from all indexes > ------------------------------------------------- > > Key: ISPN-7990 > URL: https://issues.jboss.org/browse/ISPN-7990 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 9.1.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > This may be needed in some non frequent scenarios (happening during topology changes) where a write command cannot obtain the previous value to remove it from the index. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8008) Add Fault-tolerance to write-behind stores

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-8008?page=com.atlassian.jira.plugin.... ] Ryan Emerson commented on ISPN-8008: ------------------------------------ Adding [~vbchin2]'s comment here so the discussion is in one place: {quote} Currently, I believe, the flush only works if the passivation is set to true. So, I think we should try to make it (#2 above) to work even if passivation is set to false. {quote} > Add Fault-tolerance to write-behind stores > ------------------------------------------ > > Key: ISPN-8008 > URL: https://issues.jboss.org/browse/ISPN-8008 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Ryan Emerson > Assignee: Ryan Emerson > > Currently when a store is configured to be write-behind, three attempts are made to write the queued modifications to the store. If all three attempts fail, then this error is simply logged and the modifications are never written to the store. > We should allow users to configure a write-behind store so that: In the event that a write-behind fails, further operations on the cache are not allowed and the modifications which failed to write to the store are queued indefinitely. Once the underlying store becomes available, the queued modifications should be written and then the cache should become available. > To determine whether a store has become available again, the AsyncCacheWriter will have to poll the store's availability. Currently the CacheWriter interface does not allow such behaviour, therefore there are two options: > * Attempt a write and catch an exception if the store is not currently available > * Add a method to return the current status of a store to the CacheWriter interface -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2082) JdbcStringBasedCacheStore: ORA-24816 when storing BLOB values > 4000 bytes

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2082?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2082: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.1.0.Final 9.0.4.Final 9.1.0.CR2 Resolution: Done > JdbcStringBasedCacheStore: ORA-24816 when storing BLOB values > 4000 bytes > -------------------------------------------------------------------------- > > Key: ISPN-2082 > URL: https://issues.jboss.org/browse/ISPN-2082 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.1.5.FINAL > Environment: OS X 10.7.4, JDK 1.7.0u4 > Reporter: Ryan Scharer > Assignee: Ryan Emerson > Fix For: 9.1.0.Final, 9.0.4.Final, 9.1.0.CR2 > > > I've configured a JdbcStringBasedCacheStore with a VARCHAR(4000) key column and a BLOB value column. If I try to store a BLOB value of less than 4000 bytes, everything works fine. If the value is greater, the cache store fails with ORA-24816. This occurs because the BLOB column is not the last one in the PreparedStatement SQL as the Oracle driver requires. My current, sad workaround is to clone the JdbcStringBasedCacheStore implementation and write my own insert/update SQL in storeLockSafe(). This works fine, but obviously isn't ideal from an upgrade point of view. Simply overriding storeLockSafe() isn't an option due to all the private fields. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8006) Avoid more toHexString usages

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8006?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8006: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5261 > Avoid more toHexString usages > ----------------------------- > > Key: ISPN-8006 > URL: https://issues.jboss.org/browse/ISPN-8006 > Project: Infinispan > Issue Type: Task > Affects Versions: 9.1.0.CR1, 9.0.3.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.1.0.Final, 9.0.4.Final > > > Method should not be used to print out potentially big value, eg. keys, message bodies...etc. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2017