[JBoss JIRA] (ISPN-10489) Deploy ServerNG distribution zip with SNAPSHOT builds
by Ryan Emerson (Jira)
Ryan Emerson created ISPN-10489:
-----------------------------------
Summary: Deploy ServerNG distribution zip with SNAPSHOT builds
Key: ISPN-10489
URL: https://issues.jboss.org/browse/ISPN-10489
Project: Infinispan
Issue Type: Enhancement
Components: Build
Affects Versions: 10.0.0.Beta5
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Fix For: 10.0.0.CR1
In order to facilitate nightly builds of the infinispan image, it's necessary for the ServerNG zip to be deployed as part of our snapshot releases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-10488) Infinispan Version is not printed in Quarkus native mode
by Will Burns (Jira)
[ https://issues.jboss.org/browse/ISPN-10488?page=com.atlassian.jira.plugin... ]
Will Burns commented on ISPN-10488:
-----------------------------------
Looking further we should probably stop using the package version info and instead use the Version class in the commons module.
> Infinispan Version is not printed in Quarkus native mode
> --------------------------------------------------------
>
> Key: ISPN-10488
> URL: https://issues.jboss.org/browse/ISPN-10488
> Project: Infinispan
> Issue Type: Sub-task
> Components: Quarkus
> Affects Versions: 10.0.0.Beta5
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.CR1
>
>
> The client prints out the version of Infinispan at startup. Unfortunately for the client the VERSION String is computed at runtime on each invocation. Unfortunately in native mode we don't have the package implementation version available. Instead we should write this version to a static variable that is readable during native runtime. Note this is already handled for the server as it is written to a static variable.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-10488) Infinispan Version is not printed in Quarkus native mode
by Will Burns (Jira)
Will Burns created ISPN-10488:
---------------------------------
Summary: Infinispan Version is not printed in Quarkus native mode
Key: ISPN-10488
URL: https://issues.jboss.org/browse/ISPN-10488
Project: Infinispan
Issue Type: Sub-task
Components: Quarkus
Affects Versions: 10.0.0.Beta5
Reporter: Will Burns
Assignee: Will Burns
Fix For: 10.0.0.CR1
The client prints out the version of Infinispan at startup. Unfortunately for the client the VERSION String is computed at runtime on each invocation. Unfortunately in native mode we don't have the package implementation version available. Instead we should write this version to a static variable that is readable during native runtime. Note this is already handled for the server as it is written to a static variable.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (ISPN-6494) Investigate bundler performance
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/ISPN-6494?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-6494:
--------------------------------
A single node == not clustered? Then the bundler won't be hit anyway, as messages will be looped back up the stack...
Re: exposing the MBeans: you may also want to enable diagnostics, so you can run probe.sh to fetch information about the cluster members across processes, e.g. messages rejected by the thread pool, number of retransmissions etc
I'm also available for a phone call to do some interactive tuning if you want to.
Cheers,
> Investigate bundler performance
> -------------------------------
>
> Key: ISPN-6494
> URL: https://issues.jboss.org/browse/ISPN-6494
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> For ISPN-6027 we changed the default JGroups bundler to {{sender-sends-with-timer}}, because it was faster in some of the performance tests. However, IspnPerfTest shows {{transfer-queue-bundler}} to be consistently better, so we need to investigate the bundler choice again.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months
[JBoss JIRA] (IPROTO-109) AutoProtoSchemaBuilder fails due to mismatched @ProtoFactory signature during incremental compilation
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/IPROTO-109?page=com.atlassian.jira.plugin... ]
Nistor Adrian resolved IPROTO-109.
----------------------------------
Resolution: Won't Fix
This is caused by a javac bug in jdk 8 that was solved in 9: https://bugs.openjdk.java.net/browse/JDK-8191074
It only happens during incremental compilation. So it's likely to see this while compiling from and IDE like Intellij, but very unlikely while doing a compile from maven.
There is no fix or workaround on our side for making this work on jdk 8. We cannot do anything about it, just switch to jdk 11 (or later) and use a java 8 target, if you really must use java 8. This is confirmed to make the issue dissapear.
> AutoProtoSchemaBuilder fails due to mismatched @ProtoFactory signature during incremental compilation
> -----------------------------------------------------------------------------------------------------
>
> Key: IPROTO-109
> URL: https://issues.jboss.org/browse/IPROTO-109
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.0.Alpha10
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.3.0.Alpha11
>
>
> {noformat}
> Error:(29, 1) java: org.infinispan.protostream.annotations.ProtoSchemaBuilderException: @ProtoFactory annotated static method or constructor signature mismatch. The parameter 'numericVersion' does not match the field definition: EmbeddedExpirableMetadata(long,long,org.infinispan.container.versioning.NumericVersion,org.infinispan.container.versioning.SimpleClusteredVersion)
> at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.scanMemberAnnotations(ProtoMessageTypeMetadata.java:213)
> at org.infinispan.protostream.annotations.impl.BaseProtoSchemaGenerator.generateAndRegister(BaseProtoSchemaGenerator.java:116)
> at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.processClass(AutoProtoSchemaBuilderAnnotationProcessor.java:287)
> at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.processElement(AutoProtoSchemaBuilderAnnotationProcessor.java:218)
> at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.processDependencies(AutoProtoSchemaBuilderAnnotationProcessor.java:344)
> at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.processClass(AutoProtoSchemaBuilderAnnotationProcessor.java:279)
> at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.processElement(AutoProtoSchemaBuilderAnnotationProcessor.java:218)
> at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.process(AutoProtoSchemaBuilderAnnotationProcessor.java:171)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035)
> at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176)
> at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
> at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
> at com.sun.tools.javac.main.Main.compile(Main.java:523)
> at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
> at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
> at org.jetbrains.jps.javac.JavacMain.compile(JavacMain.java:195)
> at org.jetbrains.jps.incremental.java.JavaBuilder.compileJava(JavaBuilder.java:460)
> at org.jetbrains.jps.incremental.java.JavaBuilder.compile(JavaBuilder.java:330)
> at org.jetbrains.jps.incremental.java.JavaBuilder.doBuild(JavaBuilder.java:255)
> at org.jetbrains.jps.incremental.java.JavaBuilder.build(JavaBuilder.java:213)
> at org.jetbrains.jps.incremental.IncProjectBuilder.runModuleLevelBuilders(IncProjectBuilder.java:1324)
> at org.jetbrains.jps.incremental.IncProjectBuilder.runBuildersForChunk(IncProjectBuilder.java:1004)
> at org.jetbrains.jps.incremental.IncProjectBuilder.buildTargetsChunk(IncProjectBuilder.java:1071)
> at org.jetbrains.jps.incremental.IncProjectBuilder.buildChunkIfAffected(IncProjectBuilder.java:965)
> at org.jetbrains.jps.incremental.IncProjectBuilder.buildChunks(IncProjectBuilder.java:794)
> at org.jetbrains.jps.incremental.IncProjectBuilder.runBuild(IncProjectBuilder.java:376)
> at org.jetbrains.jps.incremental.IncProjectBuilder.build(IncProjectBuilder.java:178)
> at org.jetbrains.jps.cmdline.BuildRunner.runBuild(BuildRunner.java:139)
> at org.jetbrains.jps.cmdline.BuildSession.runBuild(BuildSession.java:288)
> at org.jetbrains.jps.cmdline.BuildSession.run(BuildSession.java:121)
> at org.jetbrains.jps.cmdline.BuildMain$MyMessageHandler.lambda$channelRead0$0(BuildMain.java:228)
> 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)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 4 months