October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10609) Extend Marshaller interface to expose configured ClassWhiteList to implementation

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10609?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10609: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > Extend Marshaller interface to expose configured ClassWhiteList to implementation > --------------------------------------------------------------------------------- > > Key: ISPN-10609 > URL: https://issues.jboss.org/browse/ISPN-10609 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 10.0.0.CR2 > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Final > > > ClassWhiteList is a generic white list that can be configured via our XML, it doesn't have anything specifc to Serialization. We should allow a user's marshaller implementation, set via SerializationConfiguration#marshaller, to utilise the configured values to limit what can/can't be marshalled. > For our internal code this is nice because it will prevent us from requiring hacky code like the following in the PersistenceMarshallerImpl if the user wants to utilise our provided JavaSerializationMarshaller: > {code:java} > if (userMarshaller instanceof JavaSerializationMarshaller) { > ((JavaSerialzationMarshaller) userMarshaller).setWhiteList(whiteListImpl); > } else if (userMarshaller instanceof ...) { > ... > } > {code} > Proposed change to the Marshaller interface: > {code:java} > default void initialize(ClassWhiteList whiteList) { > // no-op > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10721) jcache/tck-runner module should not unpack cache-tests

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10721?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10721: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > jcache/tck-runner module should not unpack cache-tests > ------------------------------------------------------ > > Key: ISPN-10721 > URL: https://issues.jboss.org/browse/ISPN-10721 > Project: Infinispan > Issue Type: Bug > Components: JCache, Test Suite - Server > Affects Versions: 10.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.0.Final > > > The {{jcache/tck-runner}} module is unpacking the {{cache-tests}} dependency (the TCK) in the target directory so that the Surefire Maven plugin can find and run the tests. > This started breaking since the upgrade to Weld 2.3.4.Final (ISPN-10383), because Weld now finds the TCK beans in two different locations: > {noformat} > [2019-10-01T07:12:01.511Z] [OK: 214, KO: 1, SKIP: 0] Test failed: InterceptionUsingCacheConfigTest.test_AT_CacheResult > [2019-10-01T07:12:01.511Z] org.jboss.weld.exceptions.AmbiguousResolutionException: WELD-001318: Cannot resolve an ambiguous dependency between: > [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default], > [2019-10-01T07:12:01.511Z] - Managed Bean [class manager.ClassLevelCacheConfigBlogManagerImpl] with qualifiers [@Any @Default] > [2019-10-01T07:12:01.511Z] at org.jboss.weld.manager.BeanManagerImpl.resolve(BeanManagerImpl.java:1235) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotations.cdi.test.CdiBeanProvider.getBeanByType(CdiBeanProvider.java:47) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractInterceptionTest.getBeanByType(AbstractInterceptionTest.java:66) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.InterceptionUsingCacheConfigTest.getBlogManager(InterceptionUsingCacheConfigTest.java:23) > [2019-10-01T07:12:01.511Z] at org.jsr107.tck.annotation.AbstractBlogManagerInterceptionTest.before(AbstractBlogManagerInterceptionTest.java:26) > {noformat} > Fortunately we don't have to unpack the tests in our working directory, we can tell Surefire to run the tests from the jar instead: > {code:xml} > <dependenciesToScan> > <dependency>javax.cache:cache-tests</dependency> > </dependenciesToScan> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10611) Jenkins ignores server/runtime test failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10611?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10611: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > Jenkins ignores server/runtime test failures > -------------------------------------------- > > Key: ISPN-10611 > URL: https://issues.jboss.org/browse/ISPN-10611 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 10.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > {{server/runtime}} test suite uses JUnit, so it should not disable the native xml report. Need > {noformat} > <disableXmlReport>false</disableXmlReport> > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10614) Creation of indexed queries via the CacheAdmin API fails

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10614?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10614: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > Creation of indexed queries via the CacheAdmin API fails > -------------------------------------------------------- > > Key: ISPN-10614 > URL: https://issues.jboss.org/browse/ISPN-10614 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 10.0.0.CR2 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Final > > > The QueryInterceptor cannot be added when a cache is created from the GlobalConfigurationManager since it happens within a persistence thread. We should use the async pool for creating/removing caches. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10618) If Expiration is enabled the cretionDate is modified to the current server start date if preload is enabled for a persistence

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10618?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10618: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > If Expiration is enabled the cretionDate is modified to the current server start date if preload is enabled for a persistence > ----------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-10618 > URL: https://issues.jboss.org/browse/ISPN-10618 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 10.0.0.CR2 > Environment: Cache configuration with preload > <local-cache name="default"> > <persistence> > <file-store shared="false" preload="true" fetch-state="true"/> > </persistence> > </local-cache> > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Blocker > Fix For: 10.0.0.Final, 9.4.17.Final > > > If a cache store entries with expiration the MetaData creationTime is used to calculate the expiration. > This works correct if the server is not restarted or preload=false for the store. > If preload is enabled and the server preload the date the creationTime is set to the current server start time. > In this case all expiration for existing entries is not working correctly -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10650) Expiration should not be replicated cross site

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10650?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10650: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > Expiration should not be replicated cross site > ---------------------------------------------- > > Key: ISPN-10650 > URL: https://issues.jboss.org/browse/ISPN-10650 > Project: Infinispan > Issue Type: Bug > Components: Cross-Site Replication, Expiration > Affects Versions: 9.4.16.Final, 10.0.0.CR2 > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Final, 9.4.17.Final > > > There is no reason currently to replicate expiration commands across site. > Lifespan will work just fine without without replicating as the entry is expired on either side properly, irrespective of system clocks. > However max idle doesn't support the given semantics with xsite. We currently only confirm from other nodes in the same cluster for max idle before removing. It would be extremely costly to query all the cross sites to see if they have a read on the same entry before expiring. Also this requires having system clocks somewhat close in time, which can be even more problematic with clusters in disparate locations. We need to document that this doesn't work as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10657) Handle async-xsite in parallel

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10657?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10657: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > Handle async-xsite in parallel > ------------------------------ > > Key: ISPN-10657 > URL: https://issues.jboss.org/browse/ISPN-10657 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication > Affects Versions: 10.0.0.CR2 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Final, 9.4.17.Final > > > Asynchronous cross-site replication relies on the ordering of the write operation to ensure data consistency. This ordering is provided by JGroups; it only delivers the next request after the first one is completed. > This order contains updates for multiple caches and keys. What is proposed here is to handle different keys/cache updates in parallel. > It should improve the response time, however, there is no free lunch. The following is expected: > * An increase of CPU utilization: it may spawn new threads to handle different keys update in parallel > * An increase in memory: it chains the updates (queue) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10666) Eviction get stuck with <off-heap> configuration and optimistic transactions

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10666?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10666: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > Eviction get stuck with <off-heap> configuration and optimistic transactions > ---------------------------------------------------------------------------- > > Key: ISPN-10666 > URL: https://issues.jboss.org/browse/ISPN-10666 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Final, 9.4.17.Final > > > If the cache is configured as followed adding entries every second will end up in an unresponsive server. > The client will stop after 120sec (eviction count reached) with > Exception in thread "main" org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException: PutOperation{ExpirationCache, key=[B0x033E17323031392D..[26], value=[B0x033F280058585858..[10244], flags=4} timed out after 60000 ms > at org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:54) > at org.infinispan.client.hotrod.impl.Util.await(Util.java:27) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:335) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:129) > at org.infinispan.wfink.hotrod.client.HotRodConstantLoadExpirationClient.putWithExpiration(HotRodConstantLoadExpirationClient.java:48) > at org.infinispan.wfink.hotrod.client.HotRodConstantLoadExpirationClient.testLoop(HotRodConstantLoadExpirationClient.java:84) > at org.infinispan.wfink.hotrod.client.HotRodConstantLoadExpirationClient.main(HotRodConstantLoadExpirationClient.java:160) > Caused by: java.net.SocketTimeoutException: PutOperation{ExpirationCache, key=[B0x033E17323031392D..[26], value=[B0x033F280058585858..[10244], flags=4} timed out after 60000 ms > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.run(HotRodOperation.java:172) > at io.netty.util.concurrent.PromiseTask$RunnableAdapter.call(PromiseTask.java:38) > at io.netty.util.concurrent.ScheduledFutureTask.run(ScheduledFutureTask.java:127) > at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163) > at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:404) > at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:322) > at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10663) TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10663?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10663: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > TypeIds in query.proto do not match those allocated in org.infinispan.commons.marshall.ProtoStreamTypeIds > --------------------------------------------------------------------------------------------------------- > > Key: ISPN-10663 > URL: https://issues.jboss.org/browse/ISPN-10663 > Project: Infinispan > Issue Type: Bug > Components: Marshalling > Affects Versions: 10.0.0.CR2 > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10668) Expiration reaper should log the number of entries removed

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10668?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10668: ----------------------------------- Fix Version/s: 10.0.0.Final (was: 10.0.0.CR3) > Expiration reaper should log the number of entries removed > ---------------------------------------------------------- > > Key: ISPN-10668 > URL: https://issues.jboss.org/browse/ISPN-10668 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Final, 9.4.17.Final > > > To track the expiration process the reaper should log messages which show the number of expired and removed entry per cache additional to the start/stop and duration which can be seen at this point -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 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 October 2019