[JBoss JIRA] (ISPN-11129) High Availability for non-shared indexes on DIST caches
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11129?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11129:
-------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/7768, https://github.com/infinispan/infinispan/pull/7762, https://github.com/infinispan/infinispan/pull/7792 (was: https://github.com/infinispan/infinispan/pull/7768, https://github.com/infinispan/infinispan/pull/7762)
> High Availability for non-shared indexes on DIST caches
> -------------------------------------------------------
>
> Key: ISPN-11129
> URL: https://issues.redhat.com/browse/ISPN-11129
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.4.17.Final, 10.1.1.Final
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 10.1.2.Final, 11.0.0.Final
>
>
> 'Non-shared indexes' is a setup when each node has a local index backed by the file system, using either the near-real-time or the FS index managers.
> For REPL caches, a full copy of the index is kept in each node. As long as at least on node is up the queries hit the local index which represents the full index of the data.
> But non-shared indexes has some drawbacks for DIST caches: each node only indexes data that the node is the primary owner. If a node goes down, there is no redundancy. This issue aims to solve this issue at two levels:
> * Indexing: replicated entries should be indexed for redundancy purposes. If a primary owner goes down, the entry is indexed in the backup owner. This should follow exactly the data distribution on the cache in terms of number of replicas and rebalancing
> * Querying: query broadcast is currently used for non-shared indexes. If replicated entries start to be indexed, a mechanism will have to be used to avoid retuning repeated results, since currently the broadcast simply queries all the entries in each node and join the result.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11231) Transcoder lookup is inefficient
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11231?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11231:
--------------------------------
Status: Open (was: New)
> Transcoder lookup is inefficient
> --------------------------------
>
> Key: ISPN-11231
> URL: https://issues.redhat.com/browse/ISPN-11231
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.17.Final, 10.1.1.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Alpha1
>
>
> {{EncoderRegistryImpl}} stores transcoders in a set, without any lookup optimization because it assumes the number of transcoders is small.
> However, {{InternalCacheFactory.bootstrap()}} registers a "different" {{TranscoderMarshallerAdapter}} for each cache, even though they all delegate to the same global marshaller.
> I believe the global marshaller transcoder adapter should be registered only once in {{EncoderRegistryFactory}}, and ideally we should have a way of looking up transcoders by media types.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-5950) Parser sets transaction().useSynchronization to non-default value
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-5950?page=com.atlassian.jira.plugin... ]
Dan Berindei resolved ISPN-5950.
--------------------------------
Fix Version/s: 9.0.0.Final
Resolution: Done
Fixed with ISPN-6553
> Parser sets transaction().useSynchronization to non-default value
> -----------------------------------------------------------------
>
> Key: ISPN-5950
> URL: https://issues.redhat.com/browse/ISPN-5950
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 8.0.1.Final
> Reporter: Radim Vansa
> Priority: Major
> Fix For: 9.0.0.Final
>
>
> Default value for transaction().useSynchronization() is false, so when the configuration is build programmatically, it is set to false. However, if I configure a non-transactional cache in XML and read the configuration, it is set to true.
> This complicates testing, when I want to compare programmatic and XML configurations, and generally it is inconsistent.
> When doing equals() operation on configurations. transaction-only attributes should not be compared if transactionMode == NONE, since they actually don't matter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11237) StreamDistPartitionHandlingTest.testUsingIteratorButPartitionOccursAfterRetrievingRemoteValues random failures
by Diego Lovison (Jira)
Diego Lovison created ISPN-11237:
------------------------------------
Summary: StreamDistPartitionHandlingTest.testUsingIteratorButPartitionOccursAfterRetrievingRemoteValues random failures
Key: ISPN-11237
URL: https://issues.redhat.com/browse/ISPN-11237
Project: Infinispan
Issue Type: Bug
Components: Core, Test Suite
Affects Versions: 10.1.0.Beta1
Reporter: Diego Lovison
Assignee: Will Burns
The test requests one entry from a stream iterator, then takes the cache to degraded mode, and assumes that the requesting the 2nd entry won't throw an {{AvailabilityException}} because the iterator already fetched the value in the background.
However, even though the iterator requested all the segments in parallel, there is no guarantee that the originator also got the responses. If the test installs the partition views too soon, some segments will have to be retried, and they will fail:
{noformat}
11:20:27,056 TRACE (testng-Test:[]) [JGroupsTransport] Test-NodeA-4361 sending single request 15 to Test-NodeC-45859: InitialPublisherCommand{cacheName='Test'}
11:20:27,058 TRACE (testng-Test:[]) [BasePartitionHandlingTest] Partition forming
11:20:27,066 TRACE (testng-Test:[]) [BasePartitionHandlingTest] Partition forming
11:20:27,066 TRACE (testng-Test:[]) [BasePartitionHandlingTest] Before installing new view...
11:20:27,068 TRACE (transport-thread-Test-NodeA-p48709-t6:[Topology-Test]) [CheckPoint] Waiting for event pre_released * 1
11:20:27,068 TRACE (jgroups-9,Test-NodeC-45859:[]) [JGroupsTransport] Test-NodeC-45859 sending response for request 15 to Test-NodeA-4361: SuccessfulResponse(PublisherResponse{size=0, completedSegments={6 12 15 31-33 36 40-41 44 50 53 56-57 75 78 85 89-92 97 103 113 122-123 127 130 135-136 148 173 188-189 192-193 221 224-226 238 241-242 253}, lostSegments=null, complete=true, segmentOffset=0})
11:20:27,095 TRACE (testng-Test:[]) [BasePartitionHandlingTest] New views installed
11:20:27,096 TRACE (transport-thread-Test-NodeA-p48709-t6:[Topology-Test]) [CheckPoint] Received event post_released * 1 (available = 999999998, total = 999999999)
11:20:27,100 TRACE (transport-thread-Test-NodeA-p48709-t6:[Topology-Test]) [ClusterPublisherManagerImpl] Segments {3 6 11-12 15 22 26-29 31-37 39-44 47 50 52-57 62-63 75-78 81 85-86 89-92 97 103-105 113-115 120-125 127-128 130 135-136 141 148 155-156 172-174 188-194 197 200 205 209-210 221 224-226 229 234 237-238 241-243 245 248 253-254} not completed - retrying
11:20:27,102 TRACE (transport-thread-Test-NodeA-p48709-t6:[Topology-Test]) [JGroupsTransport] Test-NodeA-4361 sending single request 18 to Test-NodeC-45859: InitialPublisherCommand{cacheName='Test'}
11:20:27,100 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.partitionhandling.StreamDistPartitionHandlingTest.testUsingIteratorButPartitionOccursAfterRetrievingRemoteValues[DIST_SYNC, DENY_READ_WRITES]
org.infinispan.partitionhandling.AvailabilityException: ISPN000305: Cluster is operating in degraded mode because of node failures.
at org.infinispan.reactive.publisher.impl.PartitionAwareClusterPublisherManager$PartitionListener.onPartitionChange(PartitionAwareClusterPublisherManager.java:52) ~[classes/:?]
at jdk.internal.reflect.GeneratedMethodAccessor336.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.lambda$invoke$1(AbstractListenerImpl.java:426) ~[classes/:?]
at org.infinispan.notifications.impl.AbstractListenerImpl$ListenerInvocationImpl.invoke(AbstractListenerImpl.java:453) ~[classes/:?]
at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.doRealInvocation(CacheNotifierImpl.java:1854) ~[classes/:?]
at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1801) ~[classes/:?]
at org.infinispan.notifications.cachelistener.CacheNotifierImpl$BaseCacheEntryListenerInvocation.invoke(CacheNotifierImpl.java:1754) ~[classes/:?]
at org.infinispan.notifications.cachelistener.CacheNotifierImpl.doNotifyPartitionStatusChanged(CacheNotifierImpl.java:868) ~[classes/:?]
at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyPartitionStatusChanged(CacheNotifierImpl.java:857) ~[classes/:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.mockito.internal.stubbing.defaultanswers.ForwardsInvocations.answer(ForwardsInvocations.java:48) ~[mockito-core-2.27.0.jar:?]
at org.infinispan.test.Mocks.lambda$blockingAnswer$0(Mocks.java:156) ~[test-classes/:?]
at org.mockito.internal.stubbing.StubbedInvocationMatcher.answer(StubbedInvocationMatcher.java:39) ~[mockito-core-2.27.0.jar:?]
at org.mockito.internal.handler.MockHandlerImpl.handle(MockHandlerImpl.java:96) ~[mockito-core-2.27.0.jar:?]
at org.mockito.internal.handler.NullResultGuardian.handle(NullResultGuardian.java:29) ~[mockito-core-2.27.0.jar:?]
at org.mockito.internal.handler.InvocationNotifierHandler.handle(InvocationNotifierHandler.java:35) ~[mockito-core-2.27.0.jar:?]
at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.doIntercept(MockMethodInterceptor.java:61) ~[mockito-core-2.27.0.jar:?]
at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.doIntercept(MockMethodInterceptor.java:49) ~[mockito-core-2.27.0.jar:?]
at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor$DispatcherDefaultingToRealMethod.interceptAbstract(MockMethodInterceptor.java:126) ~[mockito-core-2.27.0.jar:?]
at org.infinispan.notifications.cachelistener.CacheNotifier$MockitoMock$819492735.notifyPartitionStatusChanged(Unknown Source) ~[classes/:?]
at org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl.lambda$setAvailabilityMode$0(PartitionHandlingManagerImpl.java:101) ~[classes/:?]
at java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106) ~[?:?]
at java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235) ~[?:?]
at java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:143) ~[?:?]
at org.infinispan.partitionhandling.impl.PartitionHandlingManagerImpl.setAvailabilityMode(PartitionHandlingManagerImpl.java:99) ~[classes/:?]
at org.infinispan.topology.LocalTopologyManagerImpl.doHandleTopologyUpdate(LocalTopologyManagerImpl.java:354) ~[classes/:?]
at org.infinispan.topology.LocalTopologyManagerImpl.lambda$handleTopologyUpdate$1(LocalTopologyManagerImpl.java:286) ~[classes/:?]
at org.infinispan.executors.LimitedExecutor.runTasks(LimitedExecutor.java:175) ~[classes/:?]
at org.infinispan.executors.LimitedExecutor.access$100(LimitedExecutor.java:37) ~[classes/:?]
at org.infinispan.executors.LimitedExecutor$Runner.run(LimitedExecutor.java:227) ~[classes/:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11236) GracefulShutdownRestartIT fails
by Diego Lovison (Jira)
Diego Lovison created ISPN-11236:
------------------------------------
Summary: GracefulShutdownRestartIT fails
Key: ISPN-11236
URL: https://issues.redhat.com/browse/ISPN-11236
Project: Infinispan
Issue Type: Bug
Affects Versions: 10.1.0.Final
Reporter: Diego Lovison
Assignee: Tristan Tarrant
{noformat}
Error Message
Cluster did not shutdown within timeout
Stacktrace
java.lang.AssertionError: Cluster did not shutdown within timeout
at org.infinispan.commons.util.Eventually.lambda$eventually$0(Eventually.java:33)
at org.infinispan.commons.util.Eventually.eventually(Eventually.java:25)
at org.infinispan.commons.util.Eventually.eventually(Eventually.java:33)
at org.infinispan.server.resilience.GracefulShutdownRestartIT.testGracefulShutdownRestart(GracefulShutdownRestartIT.java:50)
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:566)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.infinispan.server.test.InfinispanServerTestMethodRule$1.evaluate(InfinispanServerTestMethodRule.java:69)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.infinispan.server.test.InfinispanServerRule$1.evaluate(InfinispanServerRule.java:90)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
Standard Output
[OK: 131, KO: 0, SKIP: 0] Test starting: GracefulShutdownRestartIT.testGracefulShutdownRestart
[0] STDOUT: 12:36:05,513 WARN (async-thread--p2-t6) [CONFIG] ISPN000564: Configured store 'SingleFileStore' is segmented and may use a large number of file descriptors[m
[0] STDOUT: 12:36:05,514 WARN (async-thread--p2-t6) [CONFIG] ISPN000149: Fetch persistent state and purge on startup are both disabled, cache may contain stale entries on startup[m
[0] STDOUT: 12:36:05,515 WARN (async-thread--p2-t6) [CONFIG] ISPN000149: Fetch persistent state and purge on startup are both disabled, cache may contain stale entries on startup[m
[1] STDOUT: 12:36:05,558 WARN (remote-thread--p3-t2) [CONFIG] ISPN000564: Configured store 'SingleFileStore' is segmented and may use a large number of file descriptors[m
[1] STDOUT: 12:36:05,560 WARN (remote-thread--p3-t2) [CONFIG] ISPN000149: Fetch persistent state and purge on startup are both disabled, cache may contain stale entries on startup[m
[1] STDOUT: 12:36:05,562 WARN (remote-thread--p3-t2) [CONFIG] ISPN000149: Fetch persistent state and purge on startup are both disabled, cache may contain stale entries on startup[m
[0] STDOUT: 12:36:05,771 WARN (jgroups-13,06978f4151c0-63390) [CONFIG] ISPN000149: Fetch persistent state and purge on startup are both disabled, cache may contain stale entries on startup[m
[0] STDOUT: 12:36:05,776 WARN (jgroups-13,06978f4151c0-63390) [CONFIG] ISPN000149: Fetch persistent state and purge on startup are both disabled, cache may contain stale entries on startup[m
[0] STDOUT: 12:36:05,883 INFO (transport-thread--p5-t7) [CLUSTER] [Context=C3F31F9D169B25D0C68FE5A26A6600FFA0E2E3F4]ISPN100002: Starting rebalance with members [63781b79183e-43839, 06978f4151c0-63390], phase READ_OLD_WRITE_ALL, topology id 2[m
[0] STDOUT: 12:36:05,963 INFO (remote-thread--p3-t1) [CLUSTER] [Context=C3F31F9D169B25D0C68FE5A26A6600FFA0E2E3F4]ISPN100009: Advancing to rebalance phase READ_ALL_WRITE_ALL, topology id 3[m
[0] STDOUT: 12:36:05,978 INFO (remote-thread--p3-t1) [CLUSTER] [Context=C3F31F9D169B25D0C68FE5A26A6600FFA0E2E3F4]ISPN100009: Advancing to rebalance phase READ_NEW_WRITE_ALL, topology id 4[m
[0] STDOUT: 12:36:05,985 INFO (async-thread--p2-t17) [CLUSTER] [Context=C3F31F9D169B25D0C68FE5A26A6600FFA0E2E3F4]ISPN100010: Finished rebalance with members [63781b79183e-43839, 06978f4151c0-63390], topology id 5[m
[0] STDERR: WARNING: An illegal reflective access operation has occurred
[0] STDERR: WARNING: Illegal reflective access by protostream.com.google.protobuf.UnsafeUtil (file:/opt/infinispan/lib/protostream-4.3.1.Final.jar) to field java.nio.Buffer.address
[0] STDERR: WARNING: Please consider reporting this to the maintainers of protostream.com.google.protobuf.UnsafeUtil
[0] STDERR: WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
[0] STDERR: WARNING: All illegal access operations will be denied in a future release
[1] STDERR: WARNING: An illegal reflective access operation has occurred
[1] STDERR: WARNING: Illegal reflective access by protostream.com.google.protobuf.UnsafeUtil (file:/opt/infinispan/lib/protostream-4.3.1.Final.jar) to field java.nio.Buffer.address
[1] STDERR: WARNING: Please consider reporting this to the maintainers of protostream.com.google.protobuf.UnsafeUtil
[1] STDERR: WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
[1] STDERR: WARNING: All illegal access operations will be denied in a future release
[0] STDOUT: 12:36:06,811 INFO (SINGLE_PORT-ServerIO-8-2) [CLUSTER] [Context=___protobuf_metadata]ISPN100008: Updating cache members list [63781b79183e-43839], topology id 6[m
[0] STDOUT: 12:36:06,860 INFO (SINGLE_PORT-ServerIO-8-2) [CLUSTER] [Context=C3F31F9D169B25D0C68FE5A26A6600FFA0E2E3F4]ISPN100008: Updating cache members list [63781b79183e-43839], topology id 6[m
[0] STDOUT: 12:36:06,898 INFO (SINGLE_PORT-ServerIO-8-2) [CLUSTER] [Context=memcachedCache]ISPN100008: Updating cache members list [63781b79183e-43839], topology id 6[m
[1] STDOUT: 12:36:06,904 WARN (remote-thread--p3-t2) [CLUSTER] ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=___script_cache, type=SHUTDOWN_PERFORM, sender=null, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, phase=null, actualMembers=null, throwable=null, viewId=0} java.lang.NullPointerException
[1] STDOUT: at org.infinispan.topology.LocalTopologyManagerImpl.handleCacheShutdown(LocalTopologyManagerImpl.java:743)
[1] STDOUT: at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:189)
[1] STDOUT: at org.infinispan.topology.CacheTopologyControlCommand.invokeAsync(CacheTopologyControlCommand.java:160)
[1] STDOUT: at org.infinispan.remoting.inboundhandler.GlobalInboundInvocationHandler$ReplicableCommandRunner.run(GlobalInboundInvocationHandler.java:160)
[1] STDOUT: at org.infinispan.util.concurrent.BlockingTaskAwareExecutorServiceImpl$RunnableWrapper.run(BlockingTaskAwareExecutorServiceImpl.java:215)
[1] STDOUT: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[1] STDOUT: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[1] STDOUT: at java.base/java.lang.Thread.run(Thread.java:834)
[1] STDOUT: [m
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (ISPN-11234) Transcoder lookup is inefficient
by Pedro Zapata Fernandez (Jira)
Pedro Zapata Fernandez created ISPN-11234:
---------------------------------------------
Summary: Transcoder lookup is inefficient
Key: ISPN-11234
URL: https://issues.redhat.com/browse/ISPN-11234
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.17.Final, 10.1.1.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 11.0.0.Alpha1
{{EncoderRegistryImpl}} stores transcoders in a set, without any lookup optimization because it assumes the number of transcoders is small.
However, {{InternalCacheFactory.bootstrap()}} registers a "different" {{TranscoderMarshallerAdapter}} for each cache, even though they all delegate to the same global marshaller.
I believe the global marshaller transcoder adapter should be registered only once in {{EncoderRegistryFactory}}, and ideally we should have a way of looking up transcoders by media types.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months