June 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11926) Remote JCacheManager creates two RemoteCacheManager instances

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11926?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11926: ------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remote JCacheManager creates two RemoteCacheManager instances > ------------------------------------------------------------- > > Key: ISPN-11926 > URL: https://issues.redhat.com/browse/ISPN-11926 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod, JCache > Affects Versions: 11.0.0.CR1, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > {{org.infinispan.jcache.remote.JCacheManager}} creates two {{RemoteCacheManager}} instances, one with {{forceReturnValues(false)}} and one with {{forceReturnValues(true)}}. This is wasteful, because each {{RemoteCacheManager}} will create its own server connections and threads. > It also breaks {{JCache}} listeners when the user explicitly sets the marshaller to {{org.infinispan.commons.marshall.ProtoStreamMarshaller}}, because {{JCacheManager}} registers the {{KeyValueWithPrevious}} marshaller (from {{GlobalContextInitializer}}) in only one of the managers. > The test suites work by accident: > * The {{jcache/remote}} test suite doesn't configure a marshaller, instead {{ConfigurationBuilder.build()}} creates a {{ProtostreamMarshaller}} instance (because {{jboss-marshalling}} is not on the classpath) and the next {{Configuration.build()}} call uses **the same {{ProtostreamMarshaller}} instance**, so the {{RemoteCacheManager}}s share the serialization context. > * The {{jcache/tck-runner-remote}} test suite has {{jboss-marshalling}} on the classpath from the {{server/runtime}} dependency, so it uses {{GenericJBossMarshaller}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11899) Allow application/x-java-serialized-object media type without custom marshaller

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11899?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11899: ------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow application/x-java-serialized-object media type without custom marshaller > ------------------------------------------------------------------------------- > > Key: ISPN-11899 > URL: https://issues.redhat.com/browse/ISPN-11899 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 11.0.0.Dev05 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > The server registers a {{JavaSerializationTranscoder}} to make {{application/x-java-serialized-object}} available as a request/storage media type. > The core {{EncoderRegistryFactory}} registers instead a {{JavaSerializationEncoder}}, which can be used explicitly ({{cache.withEncoding(JavaSerializationEncoder.class)}}), but is not picked up automatically when the user configures storage media type {{application/x-java-serialized-object}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11900) jboss-marshalling module missing application/x-jboss-marshalling transcoder

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11900?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11900: ------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > jboss-marshalling module missing application/x-jboss-marshalling transcoder > --------------------------------------------------------------------------- > > Key: ISPN-11900 > URL: https://issues.redhat.com/browse/ISPN-11900 > Project: Infinispan > Issue Type: Enhancement > Components: Marshalling > Affects Versions: 11.0.0.Dev05 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > The server registers a {{application/x-jboss-marshalling}} transcoder, but the transcoder should instead be registered by the {{jboss-marshalling}} module so it's available in core as well. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11898) Missing transcoder for user marshaller's media type

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11898?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11898: ------------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Missing transcoder for user marshaller's media type > --------------------------------------------------- > > Key: ISPN-11898 > URL: https://issues.redhat.com/browse/ISPN-11898 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 11.0.0.Dev05 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.0.Final > > > When the user configures a custom marshaller like {{JavaSerializationMarshaller}}, the cache needs a transcoder to wrap the user marshaller and convert between Java objects and the storage media type. Of course, if the cache's storage media type is not the same as the user marshaller's media type, another transcoder will be used, but the user marshaller transcoder needs to be available. > Currently {{EncoderRegistryFactory}} registers a transcoder wrapping the global marshaller instead, and the cache won't start: > {code:java} > GlobalConfigurationBuilder gcb = new GlobalConfigurationBuilder(); > gcb.serialization().marshaller(new JavaSerializationMarshaller()); > DefaultCacheManager manager = new DefaultCacheManager(gcb.build()); > ConfigurationBuilder builder = new ConfigurationBuilder(); > builder.encoding().mediaType(MediaType.APPLICATION_SERIALIZED_OBJECT_TYPE); > manager.createCache("cache", builder.build()); > {code} > {noformat} > org.infinispan.commons.CacheConfigurationException: Unable to inject dependencies for component class org.infinispan.encoding.DataConversion, path org.infinispan.AdvancedCache (a org.infinispan.cache.impl.EncoderCache) > Caused by: org.infinispan.commons.dataconversion.EncodingException: ISPN000492: Cannot find transcoder between 'application/x-java-object' to 'application/x-java-serialized-object' > at org.infinispan.marshall.core.EncoderRegistryImpl.getTranscoder(EncoderRegistryImpl.java:64) > at org.infinispan.encoding.DataConversion.lookupTranscoder(DataConversion.java:210) > at org.infinispan.encoding.DataConversion.injectDependencies(DataConversion.java:185) > at org.infinispan.encoding.CorePackageImpl$1.wire(CorePackageImpl.java:29) > at org.infinispan.encoding.CorePackageImpl$1.wire(CorePackageImpl.java:27) > at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeInjection(BasicComponentRegistryImpl.java:339) > ... 45 more > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11967) Support POST for actions with side effects in the REST API

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11967?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11967: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8433 > Support POST for actions with side effects in the REST API > ---------------------------------------------------------- > > Key: ISPN-11967 > URL: https://issues.redhat.com/browse/ISPN-11967 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11967) Support POST for actions with side effects in the REST API

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11967?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11967: ------------------------------------- Fix Version/s: 12.0.0.Final (was: 11.0.0.Final) > Support POST for actions with side effects in the REST API > ---------------------------------------------------------- > > Key: ISPN-11967 > URL: https://issues.redhat.com/browse/ISPN-11967 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 11.0.0.CR1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11970) RemoteCacheImpl.retrieveEntries with explicit segments is not server aware

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11970?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11970: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/8432 > RemoteCacheImpl.retrieveEntries with explicit segments is not server aware > -------------------------------------------------------------------------- > > Key: ISPN-11970 > URL: https://issues.redhat.com/browse/ISPN-11970 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > Unfortunately retrieveEntries method always chooses a random server to send a request to. This is fine when segments is not provided. However if an explicit set of segments is provided we should route the request to the address that has the most segments of the set and hasn't failed yet. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11970) RemoteCacheImpl.retrieveEntries with explicit segments is not server aware

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-11970?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-11970: ------------------------------ Status: Open (was: New) > RemoteCacheImpl.retrieveEntries with explicit segments is not server aware > -------------------------------------------------------------------------- > > Key: ISPN-11970 > URL: https://issues.redhat.com/browse/ISPN-11970 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > > Unfortunately retrieveEntries method always chooses a random server to send a request to. This is fine when segments is not provided. However if an explicit set of segments is provided we should route the request to the address that has the most segments of the set and hasn't failed yet. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11902) WriteBehindFaultToleranceTest.testBlockingOnStoreAvailabilityChange random failures

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-11902?page=com.atlassian.jira.plugi... ] Ryan Emerson resolved ISPN-11902. --------------------------------- Resolution: Done > WriteBehindFaultToleranceTest.testBlockingOnStoreAvailabilityChange random failures > ----------------------------------------------------------------------------------- > > Key: ISPN-11902 > URL: https://issues.redhat.com/browse/ISPN-11902 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite > Affects Versions: 11.0.0.CR1 > Reporter: Dan Berindei > Assignee: Will Burns > Priority: Major > Labels: testsuite_stability > Fix For: 11.0.0.Final > > Attachments: WriteBehindFaultToleranceTest.log.gz > > > It always fails for me when I run from the IDE with trace logging enabled > {noformat} > java.util.concurrent.ExecutionException: org.infinispan.persistence.spi.StoreUnavailableException: Store org.infinispan.persistence.async.AsyncNonBlockingStore@1cddb77e is unavailable > at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205) > at org.infinispan.persistence.WriteBehindFaultToleranceTest.testBlockingOnStoreAvailabilityChange(WriteBehindFaultToleranceTest.java:96) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124) > at org.testng.internal.MethodInvocationHelper$1.runTestMethod(MethodInvocationHelper.java:230) > at org.infinispan.commons.test.TestNGLongTestsHook.run(TestNGLongTestsHook.java:24) > at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:242) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:579) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:719) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:989) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.privateRun(TestRunner.java:648) > at org.testng.TestRunner.run(TestRunner.java:505) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:455) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:450) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:415) > at org.testng.SuiteRunner.run(SuiteRunner.java:364) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:84) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1208) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1137) > at org.testng.TestNG.runSuites(TestNG.java:1049) > at org.testng.TestNG.run(TestNG.java:1017) > at com.intellij.rt.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:66) > at com.intellij.rt.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:110) > Caused by: org.infinispan.persistence.spi.StoreUnavailableException: Store org.infinispan.persistence.async.AsyncNonBlockingStore@1cddb77e is unavailable > at org.infinispan.persistence.manager.PersistenceManagerImpl.checkStoreAvailability(PersistenceManagerImpl.java:1093) > at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$writeBatchToAllNonTxStores$58(PersistenceManagerImpl.java:952) > at io.reactivex.rxjava3.internal.operators.completable.CompletableUsing.subscribeActual(CompletableUsing.java:57) > at io.reactivex.rxjava3.core.Completable.subscribe(Completable.java:2850) > at io.reactivex.rxjava3.core.Completable.subscribeWith(Completable.java:2900) > at io.reactivex.rxjava3.core.Completable.toCompletionStage(Completable.java:3424) > at org.infinispan.persistence.manager.PersistenceManagerImpl.writeBatchToAllNonTxStores(PersistenceManagerImpl.java:970) > at org.infinispan.interceptors.impl.CacheWriterInterceptor.processIterableBatch(CacheWriterInterceptor.java:276) > at org.infinispan.interceptors.impl.CacheWriterInterceptor.handlePutMapCommandReturn(CacheWriterInterceptor.java:263) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:86) > at org.infinispan.interceptors.impl.CacheWriterInterceptor.visitPutMapCommand(CacheWriterInterceptor.java:253) > at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:74) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) > at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) > at org.infinispan.interceptors.DDAsyncInterceptor.visitPutMapCommand(DDAsyncInterceptor.java:89) > at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:74) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) > at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:232) > at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForManyEntriesCommand(EntryWrappingInterceptor.java:694) > at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutMapCommand(EntryWrappingInterceptor.java:433) > at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:74) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:155) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lambda$nonTxLockAndInvokeNext$3(AbstractLockingInterceptor.java:308) > at org.infinispan.interceptors.SyncInvocationStage.andHandle(SyncInvocationStage.java:69) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.nonTxLockAndInvokeNext(AbstractLockingInterceptor.java:303) > at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.handleWriteManyCommand(NonTransactionalLockingInterceptor.java:65) > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutMapCommand(AbstractLockingInterceptor.java:182) > at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:74) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) > at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutMapCommand(CacheMgmtInterceptor.java:193) > at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:74) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) > at org.infinispan.interceptors.impl.IsMarshallableInterceptor.visitPutMapCommand(IsMarshallableInterceptor.java:58) > at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:74) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:59) > at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:53) > at org.infinispan.interceptors.DDAsyncInterceptor.visitPutMapCommand(DDAsyncInterceptor.java:89) > at org.infinispan.commands.write.PutMapCommand.acceptVisitor(PutMapCommand.java:74) > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:128) > at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90) > at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:244) > at org.infinispan.cache.impl.InvocationHelper.doInvoke(InvocationHelper.java:298) > at org.infinispan.cache.impl.InvocationHelper.invoke(InvocationHelper.java:102) > at org.infinispan.cache.impl.InvocationHelper.invoke(InvocationHelper.java:84) > at org.infinispan.cache.impl.CacheImpl.putAll(CacheImpl.java:1328) > at org.infinispan.cache.impl.CacheImpl.putAll(CacheImpl.java:1796) > at org.infinispan.cache.impl.CacheImpl.putAll(CacheImpl.java:473) > at org.infinispan.cache.impl.AbstractDelegatingCache.putAll(AbstractDelegatingCache.java:459) > at org.infinispan.cache.impl.EncoderCache.putAll(EncoderCache.java:726) > at org.infinispan.persistence.WriteBehindFaultToleranceTest.lambda$testBlockingOnStoreAvailabilityChange$2(WriteBehindFaultToleranceTest.java:82) > at org.infinispan.test.AbstractInfinispanTest.lambda$fork$6(AbstractInfinispanTest.java:262) > at {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10373) Store/Loader Non blocking SPI

by Ryan Emerson (Jira)

[ https://issues.redhat.com/browse/ISPN-10373?page=com.atlassian.jira.plugi... ] Ryan Emerson resolved ISPN-10373. --------------------------------- Fix Version/s: 11.0.0.Final Resolution: Done > Store/Loader Non blocking SPI > ----------------------------- > > Key: ISPN-10373 > URL: https://issues.redhat.com/browse/ISPN-10373 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.0.Final > > > We need to add and use a non blocking SPI internally for our stores/loaders. We added ISPN-9722, which is a good step and refactored all of our internal code to use "non blocking" stores. However the stores themselves are all inherently sync even if the store itself could be non blocking. We would have to add a new SPI interface to allow for such non blocking operations. We would then remove all the explicit threading added in ISPN-9722 and move it to a wrapper around a currently sync loader instead. This way an invoking thread doesn't need to do a context switch or anything if invoking just a non blocking store operation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2020