June 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11910) Server should see application/octet-stream as protostream

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11910?page=com.atlassian.jira.plugi... ] Gustavo Fernandes commented on ISPN-11910: ------------------------------------------ The concept of 'user marshaller' should be phased out and replaced by pluggable transcoders. Since each cache can use different storage and request formats, does it still make sense to elect a 'user marshaller'? Regarding seeing MediaType A as B, and assuming formats for certain situations, all of this ambiguity could be removed by making the media type config mandatory. Or at least mandating media type in certain situations that is necessary to know the format: Query, Listeners, Filters/Converter, Iteration. > Server should see application/octet-stream as protostream > --------------------------------------------------------- > > Key: ISPN-11910 > URL: https://issues.redhat.com/browse/ISPN-11910 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 11.0.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > The server, and Infinispan in general, should use the user marshaller to read {{application/octet-stream}} and {{application/unknown}} data. > ISPN-10433 added a hack in the server (for backwards compatibility, I assume): if {{jboss-marshalling}} is on the classpath, {{org.infinispan.server.core.LifecycleCallbacks.cacheManagerStarting()}} changes the marshaller for {{application/unknown}} (but not for {{application/octet-stream}}) to {{GenericJBossMarshaller}}. > This means that {{server/core}}, {{server/hotrod}}, and {{client/hotrod-client}} tests see {{application/unknown}} as protostream, but the server distribution in {{server/runtime}} always includes {{jboss-marshalling}}, so the server distribution sees {{application/unknown}} as {{GenericJBossMarshaller}} data. > It would be much better if the server always used the user marshaller for {{application/unknown}}, and when a user needs backwards compatibility between a new server and an old client, they should configure {{GenericJBossMarshaller}} in the server. > In addition, new clients should not use {{application/unknown}} unless the marshaller does not implement {{getMediaType()}}: they know the marshaller's media type, and they should send it to the server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11940) Get entry - add expiration parameters in the body

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11940?page=com.atlassian.jira.plugi... ] Katia Aresti resolved ISPN-11940. --------------------------------- Resolution: Won't Do > Get entry - add expiration parameters in the body > ------------------------------------------------- > > Key: ISPN-11940 > URL: https://issues.redhat.com/browse/ISPN-11940 > Project: Infinispan > Issue Type: Bug > Components: REST > Affects Versions: 10.1.8.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Blocker > Labels: rest > > When we are calling 'getEntry" with cors, we are unable to read other headers than the standard ones. > which means we need to send timeToLiveSeconds created lastUsed and maxIdleTimeSeconds in the body, if such exist -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11941) Add custom response headers permissions in CORS for localhost

by Katia Aresti (Jira)

[ https://issues.redhat.com/browse/ISPN-11941?page=com.atlassian.jira.plugi... ] Katia Aresti updated ISPN-11941: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add custom response headers permissions in CORS for localhost > ------------------------------------------------------------- > > Key: ISPN-11941 > URL: https://issues.redhat.com/browse/ISPN-11941 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 11.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11943) Single MediaType ignored in JSON config

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-11943: ---------------------------------------- Summary: Single MediaType ignored in JSON config Key: ISPN-11943 URL: https://issues.redhat.com/browse/ISPN-11943 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 11.0.0.CR1 Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes Fix For: 11.0.0.Final The recently introduced single MediaType config for both keys and values is being ignored when creating a cache from JSON: {code:json} { "distributed-cache":{ "encoding":{ "media-type":"application/x-protostream" } } } {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11885) ChannelPool can get in inconsistent state with concurrent release and close of a channel

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11885?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11885: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ChannelPool can get in inconsistent state with concurrent release and close of a channel > ---------------------------------------------------------------------------------------- > > Key: ISPN-11885 > URL: https://issues.redhat.com/browse/ISPN-11885 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 10.1.8.Final > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Final > > > While working on https://github.com/infinispan/infinispan/pull/8358 I found that the changes introduced allowed for a test failure to occur much more often. Upon investigation the issue is that the channel pool can close a channel and then release it which gets it in an inconsistent state. > Looking closer it appears to be a bug in the ChannelPool class when a connection is closed before release completes. > {code} > 23:42:12,203 TRACE (DistributionRetryTest-Client-Async-1-2:[]) [ChannelPool] Closed channel [id: 0x27befd37, L:/127.0.0.1:37412 ! R:127.0.0.1/127.0.0.1:33943], created = 0, idle = false, active = 0 > 23:42:12,203 TRACE (testng-DistributionRetryTest:[]) [ChannelPool] Released channel [id: 0x27befd37, L:/127.0.0.1:37412 ! R:127.0.0.1/127.0.0.1:33943], active = -1 > {code} > Here is the trace of it working where is is released before being closed. > {code} > 23:46:42,649 TRACE (testng-DistributionRetryTest:[]) [ChannelPool] Released channel [id: 0xeb9159ef, L:/127.0.0.1:39342 - R:127.0.0.1/127.0.0.1:41537], active = 0 > 23:46:42,792 TRACE (testng-DistributionRetryTest:[]) [ChannelPool] Activated record [id: 0x0b71d548, L:/127.0.0.1:51392 - R:127.0.0.1/127.0.0.1:37881], created = 1, active = 1 > 23:46:42,793 TRACE (DistributionRetryTest-Client-Async-1-3:[]) [ChannelPool] Closed channel [id: 0xeb9159ef, L:/127.0.0.1:39342 ! R:127.0.0.1/127.0.0.1:41537], created = 0, idle = true, active = 0 > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11942) JCache CacheEntryCreatedListener got TimeoutException ISPN000299 when listener calling code which accessing the created cache value

by Sammy Chu (Jira)

Sammy Chu created ISPN-11942: -------------------------------- Summary: JCache CacheEntryCreatedListener got TimeoutException ISPN000299 when listener calling code which accessing the created cache value Key: ISPN-11942 URL: https://issues.redhat.com/browse/ISPN-11942 Project: Infinispan Issue Type: Bug Components: JCache Affects Versions: 10.1.8.Final Reporter: Sammy Chu We are running into issue when upgrading infinispan from 9.1.7.Final to 9.2.0.Final and got the TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y... We reduced our settings and finally reproduce it in a simple setup: configured a local cache (i.e. TestCache) with default settings a simple service bean ServiceA with a dummy method foo() annotated with @CacheResult(cacheName = 'TestCache'), which just return a random string a simple service bean ServiceB with a dummy method bar() which just return ServiceA.foo() a JCache CacheEntryCreatedListener which calling ServiceB.bar() and register to TestCache When calling ServiceA.foo(), expecting ServiceA will generate a random string and got cached, then trigger the cache entry created listener to notify ServiceB to regenerate its value. In Infinispan below 9.2, it works correctly. But in 9.2 onward, it will throw TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y. May I ask if this is a bug as we cannot found any documentation on this behavior change. We also tested on latest stable version (10.1.8.Final) and still have such issue. We checked versions one by one and confirmed this bug introduced between change of 9.1.7 and 9.2.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11942) JCache CacheEntryCreatedListener got TimeoutException ISPN000299 when listener calling code which accessing the created cache value

by Sammy Chu (Jira)

[ https://issues.redhat.com/browse/ISPN-11942?page=com.atlassian.jira.plugi... ] Sammy Chu updated ISPN-11942: ----------------------------- Description: We are running into issue when upgrading infinispan from 9.1.7.Final to 9.2.0.Final and got the TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y... We reduced our settings and finally reproduce it in a simple setup: # configured a local cache (i.e. TestCache) with default settings # a simple service bean ServiceA with a dummy method foo() annotated with @CacheResult(cacheName = 'TestCache'), which just return a random string # a simple service bean ServiceB with a dummy method bar() which just return ServiceA.foo() # a JCache CacheEntryCreatedListener which calling ServiceB.bar() and register to TestCache When calling ServiceA.foo(), expecting ServiceA will generate a random string and got cached, then trigger the cache entry created listener to notify ServiceB to regenerate its value. In Infinispan below 9.2, it works correctly. But in 9.2 onward, it will throw TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y. May I ask if this is a bug as we cannot found any documentation on this behavior change. We also tested on latest stable version (10.1.8.Final) and still have such issue. We checked versions one by one and confirmed this bug introduced between change of 9.1.7 and 9.2.0. was: We are running into issue when upgrading infinispan from 9.1.7.Final to 9.2.0.Final and got the TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y... We reduced our settings and finally reproduce it in a simple setup: configured a local cache (i.e. TestCache) with default settings a simple service bean ServiceA with a dummy method foo() annotated with @CacheResult(cacheName = 'TestCache'), which just return a random string a simple service bean ServiceB with a dummy method bar() which just return ServiceA.foo() a JCache CacheEntryCreatedListener which calling ServiceB.bar() and register to TestCache When calling ServiceA.foo(), expecting ServiceA will generate a random string and got cached, then trigger the cache entry created listener to notify ServiceB to regenerate its value. In Infinispan below 9.2, it works correctly. But in 9.2 onward, it will throw TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y. May I ask if this is a bug as we cannot found any documentation on this behavior change. We also tested on latest stable version (10.1.8.Final) and still have such issue. We checked versions one by one and confirmed this bug introduced between change of 9.1.7 and 9.2.0. > JCache CacheEntryCreatedListener got TimeoutException ISPN000299 when listener calling code which accessing the created cache value > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-11942 > URL: https://issues.redhat.com/browse/ISPN-11942 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 10.1.8.Final > Reporter: Sammy Chu > Priority: Major > > We are running into issue when upgrading infinispan from 9.1.7.Final to 9.2.0.Final and got the TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y... > We reduced our settings and finally reproduce it in a simple setup: > # configured a local cache (i.e. TestCache) with default settings > # a simple service bean ServiceA with a dummy method foo() annotated with @CacheResult(cacheName = 'TestCache'), which just return a random string > # a simple service bean ServiceB with a dummy method bar() which just return ServiceA.foo() > # a JCache CacheEntryCreatedListener which calling ServiceB.bar() and register to TestCache > When calling ServiceA.foo(), expecting ServiceA will generate a random string and got cached, then trigger the cache entry created listener to notify ServiceB to regenerate its value. > In Infinispan below 9.2, it works correctly. But in 9.2 onward, it will throw TimeoutException: ISPN000299: Unable to acquire lock after X seconds for key Y. May I ask if this is a bug as we cannot found any documentation on this behavior change. > We also tested on latest stable version (10.1.8.Final) and still have such issue. We checked versions one by one and confirmed this bug introduced between change of 9.1.7 and 9.2.0. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11839) Create a test to check licenses in distributions

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11839?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11839: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 11.0.0.Final Resolution: Done > Create a test to check licenses in distributions > ------------------------------------------------ > > Key: ISPN-11839 > URL: https://issues.redhat.com/browse/ISPN-11839 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 11.0.0.Dev05, 10.1.8.Final > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 11.0.0.Final > > > Create a test to check licenses in distributions -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11941) Add custom response headers permissions in CORS for localhost

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11941?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11941: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8415 > Add custom response headers permissions in CORS for localhost > ------------------------------------------------------------- > > Key: ISPN-11941 > URL: https://issues.redhat.com/browse/ISPN-11941 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 11.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11941) Add custom response headers permissions in CORS for localhost

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11941?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11941: ------------------------------------- Affects Version/s: 11.0.0.CR1 (was: 10.1.8.Final) > Add custom response headers permissions in CORS for localhost > ------------------------------------------------------------- > > Key: ISPN-11941 > URL: https://issues.redhat.com/browse/ISPN-11941 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 11.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2020