[JBoss JIRA] (ISPN-10362) Unify remove command initialization and invocation
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10362?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10362:
------------------------------------------
Sprint: DataGrid Sprint #30, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #30, DataGrid Sprint #33, DataGrid Sprint #34)
> Unify remove command initialization and invocation
> --------------------------------------------------
>
> Key: ISPN-10362
> URL: https://issues.jboss.org/browse/ISPN-10362
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> ISPN-10322 unified command initialization with {{InitializableCommand}}, but we should go further and unify initialization with invocation.
> We can replace the current {{ReplicableCommand.invokeAsync}} and {{InitializableCommand.init(ComponentRegistry()}} methods with a method {{CacheRpcCommand.invokeAsync(ComponentRegistry)}} (or maybe {{execute}}?).
> For global commands we can create a {{GlobalRpcCommand}} interface with a method {{invokeAsync(GlobalComponentRegistry)}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10385) Console Server Ng
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10385?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10385:
------------------------------------------
Sprint: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34)
> Console Server Ng
> -----------------
>
> Key: ISPN-10385
> URL: https://issues.jboss.org/browse/ISPN-10385
> Project: Infinispan
> Issue Type: Feature Request
> Components: Console
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
> Labels: console-ng
>
> Create a new console using React and Patternfly 4
> - Create react app skeleton
> - Login / splash page
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10367) Possible loss of (pessimistic) lock if a transaction will reach timeout and/or is removed
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10367?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10367:
------------------------------------------
Sprint: DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #33, DataGrid Sprint #34)
> Possible loss of (pessimistic) lock if a transaction will reach timeout and/or is removed
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-10367
> URL: https://issues.jboss.org/browse/ISPN-10367
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 10.0.0.Beta3, 9.4.15.Final
> Environment: Infinispan with pessimistic locking enabled
> Reporter: Wolf-Dieter Fink
> Assignee: Pedro Ruivo
> Priority: Critical
> Attachments: StressApp.zip
>
>
> If entries are locked, no matter whether it was done by FORCE_WRITE_LOCK flag or getAdvancedCache().lock(key), and the lock is hold longer than the current Tx timeout setting (.completedTxTimeout(...) ) the transacaction might be removed
> - if the node is blocked and expelled from the cluster (and join back later)
> - the thread processing the lock will take longer than the Tx-timeout setting
> This force to remove the Tx and free the lock.
> An indicator is the Exception below which will be shown if the Tx is timing out, it is not a (remote) access timout.
> If the originator is back after this this (ongoing) Tx is assumed new and it will continue by accident without lock.
> This can cause unexpected inconsistency!
> ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (EJB timer - 13) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Replication timeout for lt-33828
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:803)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:641)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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)
> ERROR [org.jboss.as.ejb3.timer] (EJB timer - 13) WFLYEJB0020: Error invoking timeout for timer: [id=8a53d2c3-190d-4c74-9327-8e7554e1df2c timedObjectId=embeddedStressTest-ejb.embeddedStressTest-ejb.CacheAccessSingletonBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@72c41b07 initialExpiration=Fri Jun 28 10:56:16 CEST 2019 intervalDuration(in milli sec)=1 nextExpiration=Fri Jun 28 10:56:43 CEST 2019 timerState=IN_TIMEOUT info=org.infinispan.wfink.stress.TimerInfo@47ae2053]: javax.ejb.EJBException: org.infinispan.util.concurrent.TimeoutException: Replication timeout for lt-33828
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:246)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:388)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:146)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.as.ejb3.component.singleton.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:106)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:99)
> at org.jboss.as.ejb3.timerservice.TimedObjectInvokerImpl.callTimeout(TimedObjectInvokerImpl.java:109)
> at org.jboss.as.ejb3.timerservice.TimerTask.invokeBeanMethod(TimerTask.java:189)
> at org.jboss.as.ejb3.timerservice.TimerTask.callTimeout(TimerTask.java:185)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:159)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1304)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:494)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: org.infinispan.util.concurrent.TimeoutException: Replication timeout for lt-33828
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.checkRsp(JGroupsTransport.java:803)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$1(JGroupsTransport.java:641)
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602)
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577)
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474)
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47)
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:16)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 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)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10309) Convert Remaining Parts to Non Blocking & Reduce Thread Pools
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10309?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10309:
------------------------------------------
Sprint: DataGrid Sprint #29, DataGrid Sprint #30, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #29, DataGrid Sprint #30, DataGrid Sprint #33, DataGrid Sprint #34)
> Convert Remaining Parts to Non Blocking & Reduce Thread Pools
> -------------------------------------------------------------
>
> Key: ISPN-10309
> URL: https://issues.jboss.org/browse/ISPN-10309
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> We would love to get our thread pools down to a single CPU thread pool (size = numCores) and a blocking thread pool (arbitrarily large). We may also require a scheduler pool for various options as well (limited size 1-2?).
> To do this we need to remove remnants of our blocking code as possible. Possible issues for blocking are mostly around locks and io operations.
> The persistence layer was completed with ISPN-9722 so that is not an issue.
> The requirement around locking can be relaxed if the locks are guaranteed to be small in scope and do not wrap other blocking operations. An example would be a lock such as ones in CHM as long as we don't have large blocks for functional argument types.
> If code cannot be made non blocking we must offload the operation to the blocking thread pool. Care must be taken to ensure that once the blocking portion of code is completed that we switch back the to CPU thread pool as soon as possible. The listener API for example is violating this and will run code in Infinispan from any thread that completes the listener that could be done from a user.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-10409) ByteBuf leak in the REST Server
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10409?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10409:
------------------------------------------
Sprint: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34)
> ByteBuf leak in the REST Server
> -------------------------------
>
> Key: ISPN-10409
> URL: https://issues.jboss.org/browse/ISPN-10409
> Project: Infinispan
> Issue Type: Bug
> Components: REST
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
> Fix For: 10.0.0.Beta5
>
>
> From the Netty ResourceLeakDetector:
> {noformat}
> [0m[40.039s][info ][gc] GC(6) Pause Young (Normal) (G1 Evacuation Pause) 812M->114M(16384M) 136.927ms
> [31m08:31:03,559 ERROR [io.netty.util.ResourceLeakDetector] (REST-ServerIO-8-12) LEAK: ByteBuf.release() was not called before it's garbage-collected. See http://netty.io/wiki/reference-counted-objects.html for more information.
> Recent access records:
> Created at:
> io.netty:ispn-10.0@4.1.30.Final//io.netty.buffer.AbstractByteBufAllocator.compositeDirectBuffer(AbstractByteBufAllocator.java:221)
> io.netty:ispn-10.0@4.1.30.Final//io.netty.buffer.AbstractByteBufAllocator.compositeBuffer(AbstractByteBufAllocator.java:199)
> io.netty:ispn-10.0@4.1.30.Final//io.netty.handler.codec.MessageAggregator.decode(MessageAggregator.java:255)
> io.netty:ispn-10.0@4.1.30.Final//io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:88)
> io.netty:ispn-10.0@4.1.30.Final//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> io.netty:ispn-10.0@4.1.30.Final//io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> io.netty:ispn-10.0@4.1.30.Final//io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> io.netty:ispn-10.0@4.1.30.Final//io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (IPROTO-13) Proto parser does not detect duplicate enum constant names
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/IPROTO-13?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez updated IPROTO-13:
-----------------------------------------
Sprint: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34)
> Proto parser does not detect duplicate enum constant names
> ----------------------------------------------------------
>
> Key: IPROTO-13
> URL: https://issues.jboss.org/browse/IPROTO-13
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 3.0.5.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.0.0.Alpha6, 4.0.0.Final
>
>
> This should generate an error:
> {code}
> enum E {
> A = 1;
> A = 2;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (IPROTO-113) Generated marshallers for Interface enums don't compile
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/IPROTO-113?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated IPROTO-113:
------------------------------------------
Sprint: DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #34)
> Generated marshallers for Interface enums don't compile
> -------------------------------------------------------
>
> Key: IPROTO-113
> URL: https://issues.jboss.org/browse/IPROTO-113
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.0.Alpha11
> Reporter: Ryan Emerson
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.3.0.Alpha12
>
>
> For example:
> {code:java}
> public interface User {
> enum Gender {
> @ProtoEnumValue(number = 1)
> MALE,
> @ProtoEnumValue(number = 2)
> FEMALE
> }
> }
> {code}
> The generated marshaller does not compile as it tries to access Gender via '$' instead of '.'.
> {code:java}
> public final class Gender$___Marshaller_50930fab395a4317bcf1c7a7787bb360b5248d1517560bce47017d9c5477c52a implements org.infinispan.protostream.EnumMarshaller<org.infinispan.query.dsl.embedded.testdomain.User.Gender> {
> @Override
> public Class<org.infinispan.query.dsl.embedded.testdomain.User.Gender> getJavaClass() { return org.infinispan.query.dsl.embedded.testdomain.User.Gender.class; }
>
> @Override
> public String getTypeName() { return "org.infinispan.test.query.Gender"; }
>
> @Override
> public org.infinispan.query.dsl.embedded.testdomain.User.Gender decode(int $1) {
> switch ($1) {
> case 1: return org.infinispan.query.dsl.embedded.testdomain.User$Gender.MALE;
> case 2: return org.infinispan.query.dsl.embedded.testdomain.User$Gender.FEMALE;
> default: return null;
> }
> }
>
> @Override
> public int encode(org.infinispan.query.dsl.embedded.testdomain.User.Gender $1) throws IllegalArgumentException {
> switch ($1.ordinal()) {
> case 0: return 1;
> case 1: return 2;
> default: throw new IllegalArgumentException("Unexpected org.infinispan.query.dsl.embedded.testdomain.User.Gender enum value : " + $1.name());
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (IPROTO-115) Processor unable to use Pojos that have WrappedMessage fields
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/IPROTO-115?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated IPROTO-115:
------------------------------------------
Sprint: DataGrid Sprint #34, DataGrid Sprint #35 (was: DataGrid Sprint #34)
> Processor unable to use Pojos that have WrappedMessage fields
> -------------------------------------------------------------
>
> Key: IPROTO-115
> URL: https://issues.jboss.org/browse/IPROTO-115
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.3.0.Alpha11
> Reporter: Ryan Emerson
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.3.0.Alpha12
>
>
> {code:java}
> class ComplexKey {
> @ProtoField(number = 1)
> String id;
> @ProtoField(number = 2, defaultValue = "0")
> Float ratio;
> @ProtoField(number = 3)
> WrappedMessage example;
> ComplexKey(String id, Float ratio) {
> this.id = id;
> this.ratio = ratio;
> }
> @ProtoFactory
> public ComplexKey(String id, Float ratio, WrappedMessage example) {
> this.id = id;
> this.ratio = ratio;
> this.example = example;
> }
> @Override
> public boolean equals(Object o) {
> if (this == o) return true;
> if (o == null || getClass() != o.getClass()) return false;
> ComplexKey that = (ComplexKey) o;
> return Objects.equals(id, that.id) &&
> Objects.equals(ratio, that.ratio);
> }
> @Override
> public int hashCode() {
> return Objects.hash(id, ratio);
> }
> }
> {code}
> Results in the following compile-time error:
> {code}
> [ERROR] /home/remerson/workspace/RedHat/infinispan/infinispan-alt/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/transcoding/DataFormatTest.java:[325,4] org.infinispan.protostream.annotations.ProtoSchemaBuilderException: The class org.infinispan.protostream.WrappedMessage must be instantiable using an accessible no-argument constructor.
> [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.checkInstantiability(ProtoMessageTypeMetadata.java:279)
> [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.<init>(ProtoMessageTypeMetadata.java:70)
> [ERROR] at org.infinispan.protostream.annotations.impl.BaseProtoSchemaGenerator.makeProtoTypeMetadata(BaseProtoSchemaGenerator.java:250)
> [ERROR] at org.infinispan.protostream.annotations.impl.BaseProtoSchemaGenerator.scanAnnotations(BaseProtoSchemaGenerator.java:236)
> [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.getProtobufType(ProtoMessageTypeMetadata.java:816)
> [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.discoverFields(ProtoMessageTypeMetadata.java:346)
> [ERROR] at org.infinispan.protostream.annotations.impl.ProtoMessageTypeMetadata.scanMemberAnnotations(ProtoMessageTypeMetadata.java:178)
> [ERROR] at org.infinispan.protostream.annotations.impl.BaseProtoSchemaGenerator.generateAndRegister(BaseProtoSchemaGenerator.java:116)
> [ERROR] at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.processClass(AutoProtoSchemaBuilderAnnotationProcessor.java:304)
> [ERROR] at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.processElement(AutoProtoSchemaBuilderAnnotationProcessor.java:235)
> [ERROR] at org.infinispan.protostream.annotations.impl.processor.AutoProtoSchemaBuilderAnnotationProcessor.process(AutoProtoSchemaBuilderAnnotationProcessor.java:181)
> [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:980)
> [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:896)
> [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1222)
> [ERROR] at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1334)
> [ERROR] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1258)
> [ERROR] at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:936)
> [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
> [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:147)
> [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
> [ERROR] at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
> [ERROR] at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126)
> [ERROR] at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174)
> [ERROR] at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1129)
> [ERROR] at org.apache.maven.plugin.compiler.TestCompilerMojo.execute(TestCompilerMojo.java:181)
> [ERROR] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> [ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> [ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> [ERROR]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months