January 2020 - infinispan-issues - Jboss List Archives

[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: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7801, https://github.com/infinispan/infinispan/pull/7802 > 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)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11141) Spring Boot 2.2.2

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11141?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11141: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Spring Boot 2.2.2 > ----------------- > > Key: ISPN-11141 > URL: https://issues.redhat.com/browse/ISPN-11141 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Affects Versions: 9.4.16.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9784) Remove Distributed Executor

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-9784?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-9784: ------------------------------ Fix Version/s: 9.4.18.Final > Remove Distributed Executor > --------------------------- > > Key: ISPN-9784 > URL: https://issues.redhat.com/browse/ISPN-9784 > Project: Infinispan > Issue Type: Sub-task > Components: Clustered Executor > Affects Versions: 10.0.0.Alpha1 > Reporter: Tristan Tarrant > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.Beta1, 10.0.0.Final, 9.4.18.Final > > > Remove Distributed Executor in favor of Clustered Executor -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11245) default logging is with simplified classnames "c{1}" but full names are expected

by Wolf-Dieter Fink (Jira)

[ https://issues.redhat.com/browse/ISPN-11245?page=com.atlassian.jira.plugi... ] Wolf-Dieter Fink updated ISPN-11245: ------------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/7800 pattern is now the full category > default logging is with simplified classnames "c{1}" but full names are expected > -------------------------------------------------------------------------------- > > Key: ISPN-11245 > URL: https://issues.redhat.com/browse/ISPN-11245 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Major > > It will be confusing if the class names are not fully shown because > - not clear which part is logging (jgroups, infinispan, custom classes) > - infinispan classes might be not unique > - application classes might use similar names to infinispan > - application classes might not have unique names > For this the full category should be shown as before -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11245) default logging is with simplified classnames "c{1}" but full names are expected

by Wolf-Dieter Fink (Jira)

[ https://issues.redhat.com/browse/ISPN-11245?page=com.atlassian.jira.plugi... ] Wolf-Dieter Fink reassigned ISPN-11245: --------------------------------------- Assignee: Wolf-Dieter Fink > default logging is with simplified classnames "c{1}" but full names are expected > -------------------------------------------------------------------------------- > > Key: ISPN-11245 > URL: https://issues.redhat.com/browse/ISPN-11245 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Major > > It will be confusing if the class names are not fully shown because > - not clear which part is logging (jgroups, infinispan, custom classes) > - infinispan classes might be not unique > - application classes might use similar names to infinispan > - application classes might not have unique names > For this the full category should be shown as before -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11245) default logging is with simplified classnames "c{1}" but full names are expected

by Wolf-Dieter Fink (Jira)

[ https://issues.redhat.com/browse/ISPN-11245?page=com.atlassian.jira.plugi... ] Wolf-Dieter Fink updated ISPN-11245: ------------------------------------ Status: Open (was: New) > default logging is with simplified classnames "c{1}" but full names are expected > -------------------------------------------------------------------------------- > > Key: ISPN-11245 > URL: https://issues.redhat.com/browse/ISPN-11245 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Major > > It will be confusing if the class names are not fully shown because > - not clear which part is logging (jgroups, infinispan, custom classes) > - infinispan classes might be not unique > - application classes might use similar names to infinispan > - application classes might not have unique names > For this the full category should be shown as before -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11245) default logging is with simplified classnames "c{1}" but full names are expected

by Wolf-Dieter Fink (Jira)

[ https://issues.redhat.com/browse/ISPN-11245?page=com.atlassian.jira.plugi... ] Work on ISPN-11245 started by Wolf-Dieter Fink. ----------------------------------------------- > default logging is with simplified classnames "c{1}" but full names are expected > -------------------------------------------------------------------------------- > > Key: ISPN-11245 > URL: https://issues.redhat.com/browse/ISPN-11245 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Priority: Major > > It will be confusing if the class names are not fully shown because > - not clear which part is logging (jgroups, infinispan, custom classes) > - infinispan classes might be not unique > - application classes might use similar names to infinispan > - application classes might not have unique names > For this the full category should be shown as before -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11245) default logging is with simplified classnames "c{1}" but full names are expected

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-11245: --------------------------------------- Summary: default logging is with simplified classnames "c{1}" but full names are expected Key: ISPN-11245 URL: https://issues.redhat.com/browse/ISPN-11245 Project: Infinispan Issue Type: Enhancement Reporter: Wolf-Dieter Fink It will be confusing if the class names are not fully shown because - not clear which part is logging (jgroups, infinispan, custom classes) - infinispan classes might be not unique - application classes might use similar names to infinispan - application classes might not have unique names For this the full category should be shown as before -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11210) Classloading issues when using annotation generated marshallers in deployed server tasks

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11210?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11210: ------------------------------- Fix Version/s: 9.4.18.Final > Classloading issues when using annotation generated marshallers in deployed server tasks > ---------------------------------------------------------------------------------------- > > Key: ISPN-11210 > URL: https://issues.redhat.com/browse/ISPN-11210 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.0.Final, 10.0.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 9.4.18.Final, 10.1.2.Final, 11.0.0.Alpha1 > > > A server task is deployed and the task generates annotation based protostream marshallers during context init. > A NullPointerException is thrown as seen in this stacktrace, but this is another issue in javassist which obscures the real reason, a java.lang.NoClassDefFoundError: org/infinispan/protostream/ImmutableSerializationContext. > The NoClassDefFoundError is caused by the use of the thread context classloader in the ClassPool of javassist. The TCL is not always suitable. At least it never is for deployed server tasks. There is no workaround for this, and the only option is to modify ProtoSchemaBuilder.build signature, or add an overloaded method that also accepts a ClassLoader so the user can take control. > {code} > 18:40:18,528 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderPerCacheInboundInvocationHandler] (remote-thread--p2-t1) ISPN000071: Caught exception when handling command DistributedExecuteCommand [cache=Cache 'addressbook'@manapakam, keys=[], callable=org.infinispan.server.infinispan.task.DistributedServerTask@5403bdfd]: org.infinispan.protostream.annotations.ProtoSchemaBuilderException: Failed to generate marshaller implementation class > at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:144) > at org.infinispan.protostream.annotations.ProtoSchemaBuilder.build(ProtoSchemaBuilder.java:235) > at test.cacheloader.impl.RemoveObjectsTask.setTaskContext(RemoveObjectsTask.java:57) > at org.infinispan.server.infinispan.task.ServerTaskWrapper.inject(ServerTaskWrapper.java:43) > at org.infinispan.server.infinispan.task.DistributedServerTask.call(DistributedServerTask.java:46) > at org.infinispan.commands.read.DistributedExecuteCommand.invokeAsync(DistributedExecuteCommand.java:99) > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:117) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71) > at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40) > 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) > Caused by: java.lang.NullPointerException > at protostream.javassist.CannotCompileException.<init>(CannotCompileException.java:77) > at protostream.javassist.util.proxy.DefineClassHelper.toClass(DefineClassHelper.java:249) > at protostream.javassist.ClassPool.toClass(ClassPool.java:1120) > at protostream.javassist.ClassPool.toClass(ClassPool.java:1083) > at protostream.javassist.ClassPool.toClass(ClassPool.java:1041) > at protostream.javassist.CtClass.toClass(CtClass.java:1278) > at org.infinispan.protostream.annotations.impl.MarshallerCodeGenerator.generateMessageMarshaller(MarshallerCodeGenerator.java:230) > at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateMarshallers(ProtoSchemaGenerator.java:172) > at org.infinispan.protostream.annotations.impl.ProtoSchemaGenerator.generateAndRegister(ProtoSchemaGenerator.java:142) > ... 12 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11244) HotRodIteratorReapTest random failures

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/ISPN-11244?page=com.atlassian.jira.plugi... ] Dan Berindei updated ISPN-11244: -------------------------------- Status: Open (was: New) > HotRodIteratorReapTest random failures > -------------------------------------- > > Key: ISPN-11244 > URL: https://issues.redhat.com/browse/ISPN-11244 > Project: Infinispan > Issue Type: Bug > Components: Server, Test Suite > Affects Versions: 10.1.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 11.0.0.Alpha1 > > > {noformat} > 10:39:16,244 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.server.hotrod.HotRodIteratorReapTest.testIterationStateReaperOnClosedConnections > java.lang.AssertionError: expected:<0> but was:<9> > at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:252) ~[testng-6.14.3.jar:?] > at org.infinispan.server.hotrod.HotRodIteratorReapTest.testIterationStateReaperOnClosedConnections(HotRodIteratorReapTest.java:34) ~[test-classes/:?] > {noformat} > I think it fails because Netty closes the socket asynchronously, doesn't wait for the orderly shutdown. Plus the server reacts and reaps the iteration after the close, it doesn't block the client's close while doing that. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2020