[JBoss JIRA] (IPROTO-109) AutoProtoSchemaBuilder fails due to mismatched @ProtoFactory signature during incremental compilation
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/IPROTO-109?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated IPROTO-109:
-----------------------------------
Sprint: DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> 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.13.8#713008)
6 years, 4 months
[JBoss JIRA] (IPROTO-110) Protostream should not expose dependencies on the artifacts it already includes in the uberjar
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/IPROTO-110?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated IPROTO-110:
-----------------------------------
Sprint: DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> Protostream should not expose dependencies on the artifacts it already includes in the uberjar
> ----------------------------------------------------------------------------------------------
>
> Key: IPROTO-110
> URL: https://issues.jboss.org/browse/IPROTO-110
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Affects Versions: 4.2.3.Final, 4.3.0.Alpha10
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.2.4.Final, 4.3.0.Alpha11
>
>
> Javassist, protobuf-java, protoparser are such examples. Marking them provided + optional should be nicer
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-9968) JCacheStateAwarenessIT failure due to infinispan-remote dependency
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9968?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9968:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> JCacheStateAwarenessIT failure due to infinispan-remote dependency
> ------------------------------------------------------------------
>
> Key: ISPN-9968
> URL: https://issues.jboss.org/browse/ISPN-9968
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 10.0.0.Beta1
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 9.4.7.Final, 10.0.0.Beta1
>
>
> ISPN-9554 introduced a dependency on {{infinispan-remote}} on the server/integration/testsuite that results in classes not being loaded as expected. We should remove this dependency and find an alternative solution for ISPN-9554.
> JCacheStateAwarenessIT failure cause:
> {code:java}
> Caused by: java.lang.IllegalArgumentException: Logger implementation class org.infinispan.jcache.logging.Log_$logger has no matching constructor
> at org.jboss.logging.Logger$1.run(Logger.java:2562) ~[?:?]
> at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2529) ~[?:?]
> at org.jboss.logging.Logger.getMessageLogger(Logger.java:2516) ~[?:?]
> at org.infinispan.commons.logging.LogFactory.getLog(LogFactory.java:18) ~[?:?]
> at org.infinispan.jcache.AbstractJCachingProvider.<clinit>(AbstractJCachingProvider.java:23) ~[?:?]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) ~[?:?]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) ~[?:?]
> at java.lang.Class.newInstance(Class.java:442) ~[?:?]
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380) ~[?:?]
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-9699) Cluster member owning no data
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9699?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9699:
----------------------------------
Sprint: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: Sprint 10.0.0.Alpha1, Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> Cluster member owning no data
> -----------------------------
>
> Key: ISPN-9699
> URL: https://issues.jboss.org/browse/ISPN-9699
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Thomas Segismont
> Assignee: Katia Aresti
> Priority: Major
> Fix For: 9.4.7.Final, 10.0.0.Beta1
>
>
> Currently, you can set {{capacity-factor}} to zero on a cache if you don't want a node to own any segment.
> If you want a node to own no data at all, you could set this property on all declared caches. But this wouldn't work for internal caches anyway (locks, counters).
> It would be nice to have a global switch.
> This would be useful when your app needs to be a cluster member for discovery/membership but is deployed mostly for processing. Indeed, when such nodes are added/removed from the cluster:
> * there would be no data loss
> * the cluster would be back in healthy state faster as no data would be moved around.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-9905) Rest store should retrieve created and lastUsed TS from server
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9905?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9905:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> Rest store should retrieve created and lastUsed TS from server
> --------------------------------------------------------------
>
> Key: ISPN-9905
> URL: https://issues.jboss.org/browse/ISPN-9905
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores, REST
> Affects Versions: 10.0.0.Alpha2
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> Currently the rest store simply sets the created and lastUsed entries to the current time of the node loading an entry, instead we should retrieve this value from the server if fetchMetadata is true.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-9801) ClusterTopologyManagerImpl hangs when restarting a node with FORK
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9801?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9801:
----------------------------------
Sprint: Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: Sprint 10.0.0.Alpha2, Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> ClusterTopologyManagerImpl hangs when restarting a node with FORK
> -----------------------------------------------------------------
>
> Key: ISPN-9801
> URL: https://issues.jboss.org/browse/ISPN-9801
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Alpha1, 9.4.3.Final
> Reporter: dan.berindei
> Assignee: dan.berindei
> Priority: Major
> Fix For: 9.4.7.Final, 10.0.0.Beta1
>
>
> When a server is restarted with `kill -9` or similar, both the old node and the new one can be in the JGroups view for a while. Normally this shouldn't be a problem, but sometimes the new node doesn't receive the {{HeartBeatCommand}} and the coordinator cannot process any new view updates.
> {noformat}
> 14:29:19,981 INFO (jgroups-12,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [ClusterTopologyManagerImpl] Updating cluster members for all the caches. New list is [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:19,982 TRACE (transport-thread-Test-NodeA-p4-t14:[ViewHandling]) [JGroupsTransport] Test-NodeA sending request 9 to all: org.infinispan.topology.HeartBeatCommand@1163beb6
> 14:29:19,986 TRACE (jgroups-6,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeC: SuccessfulResponse(null)
> 14:29:19,987 TRACE (jgroups-9,Test-NodeA:[]) [JGroupsTransport] Test-NodeA received response for request 9 from Test-NodeD: SuccessfulResponse(null)
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [TCP_NIO2] Test-NodeE: received message batch of 1 messages from Test-NodeA
> 14:29:20,032 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: message Test-NodeA::39 was added to queue (not yet server)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: received Test-NodeA#38
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [NAKACK2] Test-NodeE: delivering Test-NodeA#38
> # not actually delivered :)
> 14:29:20,054 TRACE (jgroups-6,Test-NodeE:[]) [MFC] Test-NodeA used 5 credits, 1999995 remaining
> 14:29:20,149 INFO (ForkThread-1,ForkChannelRestartTest:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|4] (5) [Test-NodeA, Test-NodeB, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:21,119 DEBUG (testng-Test-1:[]) [ForkChannelRestartTest] Stopping channel Test-NodeB
> 14:29:23,319 INFO (VERIFY_SUSPECT.TimerThread-32,Test-NodeA:[]) [CLUSTER] ISPN000094: Received new cluster view for channel FORKISPN: [Test-NodeA|5] (4) [Test-NodeA, Test-NodeC, Test-NodeD, Test-NodeE]
> 14:29:23,320 TRACE (remote-thread-Test-NodeA-p2-t1:[]) [MultiTargetRequest] Target Test-NodeB of request 9 left the cluster view
> {noformat}
> So far, it looks like it's a JGroups bug similar to JGRP-2294, but we need to investigate further.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-9932) Avoid creating MarshallableEntry instances if no CacheWriter enabled
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9932?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9932:
----------------------------------
Sprint: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36, DataGrid Sprint #37 (was: Sprint 10.0.0.Beta1, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36)
> Avoid creating MarshallableEntry instances if no CacheWriter enabled
> --------------------------------------------------------------------
>
> Key: ISPN-9932
> URL: https://issues.jboss.org/browse/ISPN-9932
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Affects Versions: 10.0.0.Alpha3
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
> Fix For: 10.0.0.Beta1
>
>
> The (Dist)CacheWriterIntercepter is enabled if any loader/store is configured. The problem, is that the interceptor assumes that a CacheWriter is always configured. However, it is possible that only a CacheLoader has been configured, in which case when a write command visits the interceptor, MarshallableEntry instances are created unnecessarily in order to call the various PersistenceManager write operations.
> To avoid unnecessary allocations and the marshalling of key/value/metadata that is never stored, we should ensure that calls to PersistenceManager write methods are only called if a CacheWriter is actually configured.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months