September 2020 - infinispan-issues

[JBoss JIRA] (IPROTO-161) Maven compiler plugin 3.8.1 and Protostream seem broken

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/IPROTO-161?page=com.atlassian.jira.plugi... ] Dan Berindei commented on IPROTO-161: ------------------------------------- Reproducer without Quarkus: https://github.com/danberindei/maven-compiler-test/tree/master > Maven compiler plugin 3.8.1 and Protostream seem broken > ------------------------------------------------------- > > Key: IPROTO-161 > URL: https://issues.redhat.com/browse/IPROTO-161 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.3.Final > Reporter: Katia Aresti > Assignee: Nistor Adrian > Priority: Blocker > Fix For: 4.3.4.Final > > > Coming from a Quarkus issue, the maven compiler plugin in version 3.8.1 seems not working properly with classes compilation and generation > > Check the Quarkus issue. > > [https://github.com/quarkusio/quarkus/issues/9980] > > This might be a library problem or a maven problem > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12359) Support the flag CACHE_MODE_LOCAL for queries

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-12359: ---------------------------------------- Summary: Support the flag CACHE_MODE_LOCAL for queries Key: ISPN-12359 URL: https://issues.redhat.com/browse/ISPN-12359 Project: Infinispan Issue Type: Enhancement Components: Embedded Querying Reporter: Gustavo Fernandes This would allow to query the index in the local node only, restrict to the segments the local node is the primary owner. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12359) Support the flag CACHE_MODE_LOCAL for indexed queries

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12359?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-12359: ------------------------------------- Summary: Support the flag CACHE_MODE_LOCAL for indexed queries (was: Support the flag CACHE_MODE_LOCAL for queries) > Support the flag CACHE_MODE_LOCAL for indexed queries > ----------------------------------------------------- > > Key: ISPN-12359 > URL: https://issues.redhat.com/browse/ISPN-12359 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Gustavo Fernandes > Priority: Major > > This would allow to query the index in the local node only, restrict to the segments the local node is the primary owner. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-161) Maven compiler plugin 3.8.1 and Protostream seem broken

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/IPROTO-161?page=com.atlassian.jira.plugi... ] Dan Berindei commented on IPROTO-161: ------------------------------------- I have reproduced the problem in a simpler project that doesn't use Quarkus. After debugging it I'd say it's an aggregate of a maven-core problem (or tradition?), a maven-compiler-plugin problem introduced in 3.8.1, and a protostream problem. # When you invoke {{mvn clean compile test}}, the {{default-compile}} execution runs twice. This is because {{org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator#calculateMojoExecutions()}} (which hasn't changed in 6 years) collects the list of mojo executions in a list, and for each phase on the command-line it adds the mojo executions for that phase and its dependencies, even if some executions already exist in the list. E.g. {noformat} mojoExecutions = {java.util.ArrayList} size = 8 0 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-clean-plugin:2.5:clean {execution: default-clean}" 1 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-resources-plugin:2.6:resources {execution: default-resources}" 2 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile {execution: default-compile}" 3 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-resources-plugin:2.6:resources {execution: default-resources}" 4 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile {execution: default-compile}" 5 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-resources-plugin:2.6:testResources {execution: default-testResources}" 6 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile {execution: default-testCompile}" 7 = {org.apache.maven.plugin.MojoExecution} "org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test {execution: default-test}" {noformat} # The second execution of {{maven-compiler-plugin}} version 3.8.0 used to check that the sources haven't changed and do nothing. But that check was wrong, because it didn't check any class files, and [MCOMPILER-349|https://issues.apache.org/jira/browse/MCOMPILER-349] replaced it with another check that is also wrong, because it ({{org.apache.maven.plugin.compiler.AbstractCompilerMojo#isDependencyChanged()}}) checks for changes since the start of the build in all the classes on the module's classpath, including {{target/classes}}. This means the second execution of {{maven-compiler-plugin}} verison 3.8.1 deletes all the {{.class}} files from {{target/classes}}. It does not delete the files generated by annotation processors in {{target/generated-sources/annotations}}, but it also doesn't add them to the Javac sources parameter because {{org.apache.maven.plugin.compiler.AbstractCompilerMojo#getCompileSources()}} ignores the generated sources directory: {noformat} compileSourceRoots = {java.util.ArrayList} size = 3 0 = "/home/dan/Work/maven-compiler-test/src/main/java" 1 = "/home/dan/Work/maven-compiler-test/target/generated-sources/annotations" 2 = "/home/dan/Work/maven-compiler-test/target/generated-sources/annotations" {noformat} {noformat} sources = {java.util.HashSet} size = 2 0 = {java.io.File} "/home/dan/Work/maven-compiler-test/src/main/java/ProtoStreamContextInitializer.java" 1 = {java.io.File} "/home/dan/Work/maven-compiler-test/src/main/java/A.java" {noformat} # The protostream annotation processor sees that the generated Java source file exists with the correct checksum and doesn't overwrite it ({{org.infinispan.protostream.annotations.impl.processor.GeneratedFilesWriter.SourceFile#write()}}). But this means the generated source file is not added to Javac's sources, and Javac does not compile it to a {{.class}} file. IMO issue #1 is just the way Maven works, and it's not going to change any time soon. Issue #2 should be fixed, and I'll create an issue in the maven-compiler-plugin JIRA. Issue #3 could also be fixed by removing the checksum check in {{org.infinispan.protostream.annotations.impl.processor.GeneratedFilesWriter.SourceFile#write()}} and always writing the generated Java source file. TBH I'm not sure what's the purpose of the check is, so I'm not 100% it can be removed, but I hope it can be removed. > Maven compiler plugin 3.8.1 and Protostream seem broken > ------------------------------------------------------- > > Key: IPROTO-161 > URL: https://issues.redhat.com/browse/IPROTO-161 > Project: Infinispan ProtoStream > Issue Type: Bug > Affects Versions: 4.3.3.Final > Reporter: Katia Aresti > Assignee: Nistor Adrian > Priority: Blocker > Fix For: 4.3.4.Final > > > Coming from a Quarkus issue, the maven compiler plugin in version 3.8.1 seems not working properly with classes compilation and generation > > Check the Quarkus issue. > > [https://github.com/quarkusio/quarkus/issues/9980] > > This might be a library problem or a maven problem > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12358) org.infinispan.server.router.logging.RouterLogger uses a logging id range that conflicts with query module

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-12358?page=com.atlassian.jira.plugi... ] Nistor Adrian updated ISPN-12358: --------------------------------- Status: Open (was: New) > org.infinispan.server.router.logging.RouterLogger uses a logging id range that conflicts with query module > ---------------------------------------------------------------------------------------------------------- > > Key: ISPN-12358 > URL: https://issues.redhat.com/browse/ISPN-12358 > Project: Infinispan > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 12.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12358) org.infinispan.server.router.logging.RouterLogger uses a logging id range that conflicts with query module

by Nistor Adrian (Jira)

Nistor Adrian created ISPN-12358: ------------------------------------ Summary: org.infinispan.server.router.logging.RouterLogger uses a logging id range that conflicts with query module Key: ISPN-12358 URL: https://issues.redhat.com/browse/ISPN-12358 Project: Infinispan Issue Type: Bug Affects Versions: 10.0.0.Final Reporter: Nistor Adrian Assignee: Nistor Adrian Fix For: 12.0.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12338) Unzip tomcat only during the test phase

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12338?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12338: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.Dev04 Resolution: Done > Unzip tomcat only during the test phase > --------------------------------------- > > Key: ISPN-12338 > URL: https://issues.redhat.com/browse/ISPN-12338 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 12.0.0.Dev03 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 12.0.0.Dev04 > > > Unzip tomcat only during the test phase -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12339) Add eap profile for third-party-server project

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12339?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-12339: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.Dev04 Resolution: Done > Add eap profile for third-party-server project > ---------------------------------------------- > > Key: ISPN-12339 > URL: https://issues.redhat.com/browse/ISPN-12339 > Project: Infinispan > Issue Type: Enhancement > Components: Test Suite > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > Fix For: 12.0.0.Dev04 > > > Support wildfly zip file setting for third-party-server project -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12307) Improve media type parsing

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12307?page=com.atlassian.jira.plugi... ] Tristan Tarrant reassigned ISPN-12307: -------------------------------------- Assignee: Dan Berindei > Improve media type parsing > -------------------------- > > Key: ISPN-12307 > URL: https://issues.redhat.com/browse/ISPN-12307 > Project: Infinispan > Issue Type: Enhancement > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > > Media type parsing has some problems with double-quoted parameters: > * {{;}} and {{,}} are interpreted as parameter/media type separator even when they occur in a quoted parameter value > * {{'}} is interpreted as a quoting character, the spec says only {{"}} must be used for quoting > * Only spaces are allowed, not {{\t}}. > * Spaces are allowed in too many places, e.g. {{type / subtype}} or {{parameter = value}} > * Start and end quotes are removed from quoted parameter values, but the escaped characters inside are not unescaped. > * Quotes are not added back in {{toString()}}, which makes deserialization fail if one of the parameters included an escaped double-quote (e.g. {{type/subtype; param="\""}}). > Performance can also be improved, as we create many {{String}} instances via {{trim()}}, {{substring()}}, or {{split()}}. > The clearest explanation of the media type grammar seems to be in > https://tools.ietf.org/html/rfc7231#section-3.1.1.1 > https://tools.ietf.org/html/rfc7230#section-3.2.6 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12356) ScatteredStreamIteratorTest random failure

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-12356?page=com.atlassian.jira.plugi... ] Tristan Tarrant reassigned ISPN-12356: -------------------------------------- Assignee: Will Burns > ScatteredStreamIteratorTest random failure > ------------------------------------------ > > Key: ISPN-12356 > URL: https://issues.redhat.com/browse/ISPN-12356 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 12.0.0.Dev03 > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Dev04 > > > The test can fail randomly https://ci.infinispan.org/job/Infinispan/job/PR-8699/4/testReport/junit/o... with > {code} > java.lang.NullPointerException > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeCommand(JGroupsTransport.java:877) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeCommand(RpcManagerImpl.java:146) > at org.infinispan.reactive.publisher.impl.ClusterPublisherManagerImpl$SubscriberHandler.sendCancelCommand(ClusterPublisherManagerImpl.java:1077) > at org.infinispan.reactive.publisher.impl.InnerPublisherSubscription.run(InnerPublisherSubscription.java:93) > at io.reactivex.rxjava3.internal.operators.flowable.FlowableDoOnLifecycle$SubscriptionLambdaSubscriber.cancel(FlowableDoOnLifecycle.java:115) > at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drainLoop(SubscriptionArbiter.java:221) > at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drain(SubscriptionArbiter.java:190) > at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.cancel(SubscriptionArbiter.java:182) > at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drainLoop(SubscriptionArbiter.java:221) > at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.drain(SubscriptionArbiter.java:190) > at io.reactivex.rxjava3.internal.subscriptions.SubscriptionArbiter.cancel(SubscriptionArbiter.java:182) > at io.reactivex.rxjava3.internal.subscriptions.SubscriptionHelper.cancel(SubscriptionHelper.java:181) > at io.reactivex.rxjava3.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.run(BlockingFlowableIterable.java:173) > at io.reactivex.rxjava3.internal.operators.flowable.BlockingFlowableIterable$BlockingFlowableIterator.hasNext(BlockingFlowableIterable.java:104) > at org.infinispan.commons.util.Closeables$1.hasNext(Closeables.java:247) > at org.infinispan.stream.DistributedStreamIteratorTest.lambda$verifyNodeLeavesBeforeGettingData$0(DistributedStreamIteratorTest.java:136) > at org.infinispan.test.AbstractInfinispanTest$CallableWrapper.call(AbstractInfinispanTest.java:527) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > {code} > The assumption is that it is due to having no owner for a given segment, but further investigation is required. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 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 September 2020