July 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9337) Lock admin console dependencies

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9337?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9337: ------------------------------- Fix Version/s: 9.4.0.Alpha1 9.3.1.Final > Lock admin console dependencies > ------------------------------- > > Key: ISPN-9337 > URL: https://issues.jboss.org/browse/ISPN-9337 > Project: Infinispan > Issue Type: Task > Components: Console > Affects Versions: 9.3.0.Final, 9.2.5.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.4.0.Alpha1, 9.3.1.Final > > > As our console dependencies are getting outdated we have experienced, on a few occasions, application issues that are hard to catch and notice. We should lock our npm dependencies and not allow any tilde and caret [upgrades](https://stackoverflow.com/questions/22343224/whats-the-differen... of our dependencies. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9337) Lock admin console dependencies

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9337?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9337: ------------------------------- Status: Open (was: New) > Lock admin console dependencies > ------------------------------- > > Key: ISPN-9337 > URL: https://issues.jboss.org/browse/ISPN-9337 > Project: Infinispan > Issue Type: Task > Components: Console > Affects Versions: 9.3.0.Final, 9.2.5.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.4.0.Alpha1, 9.3.1.Final > > > As our console dependencies are getting outdated we have experienced, on a few occasions, application issues that are hard to catch and notice. We should lock our npm dependencies and not allow any tilde and caret [upgrades](https://stackoverflow.com/questions/22343224/whats-the-differen... of our dependencies. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9337) Lock admin console dependencies

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9337?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9337: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-management-console/pull/258, https://github.com/infinispan/infinispan-management-console/pull/255 > Lock admin console dependencies > ------------------------------- > > Key: ISPN-9337 > URL: https://issues.jboss.org/browse/ISPN-9337 > Project: Infinispan > Issue Type: Task > Components: Console > Affects Versions: 9.3.0.Final, 9.2.5.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.4.0.Alpha1, 9.3.1.Final > > > As our console dependencies are getting outdated we have experienced, on a few occasions, application issues that are hard to catch and notice. We should lock our npm dependencies and not allow any tilde and caret [upgrades](https://stackoverflow.com/questions/22343224/whats-the-differen... of our dependencies. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9337) Lock admin console dependencies

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9337?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9337. -------------------------------- Resolution: Done > Lock admin console dependencies > ------------------------------- > > Key: ISPN-9337 > URL: https://issues.jboss.org/browse/ISPN-9337 > Project: Infinispan > Issue Type: Task > Components: Console > Affects Versions: 9.3.0.Final, 9.2.5.Final > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.4.0.Alpha1, 9.3.1.Final > > > As our console dependencies are getting outdated we have experienced, on a few occasions, application issues that are hard to catch and notice. We should lock our npm dependencies and not allow any tilde and caret [upgrades](https://stackoverflow.com/questions/22343224/whats-the-differen... of our dependencies. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9368) StaleStateException/OptimisticLockException doesn't cause infinispan 2nd level cache to invalidate

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9368?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9368: ----------------------------------- Description: Migrated from [HHH-12207|https://hibernate.atlassian.net/browse/HHH-12207] {quote}If the hibernate 2nd level cache has a versioned entity which is less than the version in db, it will throw StaleDataException (expected), but at that point I expect hibernate to invalidate the cache so the next find will go to db to find correct version of entity. On our production, once hibernate has an old value, it just keeps throwing the exception until we manually clear the cache. EhCache seems to invalidate the cache as I would expect.{quote} was: Migrated from https://hibernate.atlassian.net/browse/HHH-12207 {quote}If the hibernate 2nd level cache has a versioned entity which is less than the version in db, it will throw StaleDataException (expected), but at that point I expect hibernate to invalidate the cache so the next find will go to db to find correct version of entity. On our production, once hibernate has an old value, it just keeps throwing the exception until we manually clear the cache. EhCache seems to invalidate the cache as I would expect.{quote} > StaleStateException/OptimisticLockException doesn't cause infinispan 2nd level cache to invalidate > -------------------------------------------------------------------------------------------------- > > Key: ISPN-9368 > URL: https://issues.jboss.org/browse/ISPN-9368 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.3.0.Final > Reporter: Galder Zamarreño > > Migrated from [HHH-12207|https://hibernate.atlassian.net/browse/HHH-12207] > {quote}If the hibernate 2nd level cache has a versioned entity which is less than the version in db, it will throw StaleDataException (expected), but at that point I expect hibernate to invalidate the cache so the next find will go to db to find correct version of entity. On our production, once hibernate has an old value, it just keeps throwing the exception until we manually clear the cache. EhCache seems to invalidate the cache as I would expect.{quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9368) StaleStateException/OptimisticLockException doesn't cause infinispan 2nd level cache to invalidate

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9368?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-9368: ---------------------------------------- More and info in HHH jira, including tests. The test created by Gail fails on master. > StaleStateException/OptimisticLockException doesn't cause infinispan 2nd level cache to invalidate > -------------------------------------------------------------------------------------------------- > > Key: ISPN-9368 > URL: https://issues.jboss.org/browse/ISPN-9368 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.3.0.Final > Reporter: Galder Zamarreño > > Migrated from [HHH-12207|https://hibernate.atlassian.net/browse/HHH-12207] > {quote}If the hibernate 2nd level cache has a versioned entity which is less than the version in db, it will throw StaleDataException (expected), but at that point I expect hibernate to invalidate the cache so the next find will go to db to find correct version of entity. On our production, once hibernate has an old value, it just keeps throwing the exception until we manually clear the cache. EhCache seems to invalidate the cache as I would expect.{quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9368) StaleStateException/OptimisticLockException doesn't cause infinispan 2nd level cache to invalidate

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9368: -------------------------------------- Summary: StaleStateException/OptimisticLockException doesn't cause infinispan 2nd level cache to invalidate Key: ISPN-9368 URL: https://issues.jboss.org/browse/ISPN-9368 Project: Infinispan Issue Type: Bug Components: Hibernate Cache Affects Versions: 9.3.0.Final Reporter: Galder Zamarreño Migrated from https://hibernate.atlassian.net/browse/HHH-12207 {quote}If the hibernate 2nd level cache has a versioned entity which is less than the version in db, it will throw StaleDataException (expected), but at that point I expect hibernate to invalidate the cache so the next find will go to db to find correct version of entity. On our production, once hibernate has an old value, it just keeps throwing the exception until we manually clear the cache. EhCache seems to invalidate the cache as I would expect.{quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9362) Break cycles in exception stack traces

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9362?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-9362: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6143 > Break cycles in exception stack traces > -------------------------------------- > > Key: ISPN-9362 > URL: https://issues.jboss.org/browse/ISPN-9362 > Project: Infinispan > Issue Type: Task > Affects Versions: 9.3.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > As most of the core became non-blocking, the exception stack traces became less relevant, because as the exception is re-thrown on multiple threads yet the stack trace only shows the initial thread. > ISPN-8893 improved this in some methods that are still blocking by catching an {{ExecutionException}}, adding it to the suppressed list of the cause, and rethrowing the cause. However, cycles in the exception trace is not properly supported by all loggers, e.g. {{logback}} only has a fix in the not yet released version 1.3.0. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9367) State transfer should preserve the creation timestamp of entries

by Dan Berindei (JIRA)

Dan Berindei created ISPN-9367: ---------------------------------- Summary: State transfer should preserve the creation timestamp of entries Key: ISPN-9367 URL: https://issues.jboss.org/browse/ISPN-9367 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 9.3.0.Final Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 9.4.0.Final State transfer inserts values with the current time as the creation time. Since the entries store the expected lifespan and not the expected expiration time, entries on the receiving node could expire much later than intended. The argument probably doesn't apply to the timestamp of the last usage. Since state transfer process could be interpreted as a reader, it should be fine to extend the update the time of the last usage both on the sending node and on the receiving node. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9365) Async store refresh

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-9365?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-9365: ------------------------------------ I think calling the loader for expired entries and returning expired entries are orthogonal issues. For the latter we definitely need additional configuration, but for the former we could decide to call the loader for expired entries based on whether it's a writer as well. A store that implements both {{CacheLoader}} and {{CacheWriter}} is expected to return the entries exactly the same as they were stored, with the same metadata, but a loader is free to return a different metadata (in this case, timestamp) every time it's queried. > Async store refresh > ------------------- > > Key: ISPN-9365 > URL: https://issues.jboss.org/browse/ISPN-9365 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: William Burns > > It has been discussed we should have some sort of configuration to allow for an always not null cache. That is that it would use expiration and/or eviction to relieve memory constraints, but would have a backing store that always produced non null entries. > It could also return expired entries and in the background recalculate the new value and replace it asynchronously. This may or may not want to be configured. > Then any cache user could always assume that a not null entry is returned. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 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 July 2018