[JBoss JIRA] (ISPN-3791) Silence "Received invalid rebalance confirmation from NodeX" exceptions
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-3791?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3791:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: (was: 10.0.0.Alpha1)
Resolution: Done
> Silence "Received invalid rebalance confirmation from NodeX" exceptions
> -----------------------------------------------------------------------
>
> Key: ISPN-3791
> URL: https://issues.jboss.org/browse/ISPN-3791
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 9.4.1.Final
>
>
> When the coordinator shuts down, it tries to shut down each of its caches first. This triggers a rebalance for the rest of the members, but the rebalance usually finishes only after the coordinator's channel also shuts down.
> The nodes who finish their state transfer will then send a REBALANCE_CONFIRM command to the new coordinator, but the new coordinator doesn't know about that rebalance (it will start the rebalance process from scratch). This results in exceptions like this in the new coordinator's log:
> {noformat}
> 12:36:04,977 WARN [org.infinispan.topology.CacheTopologyControlCommand] (remote-thread-2,ISPN-Node-1) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=MyCoolCache, type=REBALANCE_CONFIRM, sender=ISPN-Node-3-54019, joinInfo=null, topologyId=8, currentCH=null, pendingCH=null, throwable=null, viewId=4}: org.infinispan.commons.CacheException: Received invalid rebalance confirmation from ISPN-Node-3-54019 for cache MyCoolCache, we don't have a rebalance in progress
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:190) [infinispan-core-6.0.0.Final.jar:6.0.0.Final]
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:147) [infinispan-core-6.0.0.Final.jar:6.0.0.Final]
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:124) [infinispan-core-6.0.0.Final.jar:6.0.0.Final]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$4.run(CommandAwareRpcDispatcher.java:270) [infinispan-core-6.0.0.Final.jar:6.0.0.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> A simple way to avoid these warnings would be to keep track of the coordinator that initiated a particular rebalance on each node, and only send the confirmation message to that coordinator. The same warnings seem to appear on the old coordinator, when it receives a confirmation after its ClusterTopologyManager started shutting down, so we may need another check there.
> A more ambitious approach would be to keep the old rebalance when the new coordinator takes over, and have another round in the cluster state recovery asking if any members have already sent REBALANCE_CONFIRMATION commands (after the new coordinator is ready to process those commands). This should eliminate the duplicate state transfer that happens now.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9641) Using expiration with off heap doesn't subtract size properly with expiration
by William Burns (Jira)
William Burns created ISPN-9641:
-----------------------------------
Summary: Using expiration with off heap doesn't subtract size properly with expiration
Key: ISPN-9641
URL: https://issues.jboss.org/browse/ISPN-9641
Project: Infinispan
Issue Type: Bug
Components: Off Heap
Affects Versions: 9.4.0.Final
Reporter: William Burns
Assignee: William Burns
Fix For: 9.4.1.Final, 10.0.0.Alpha1
The OffHeapEntryFactoryImpl#getSize method is invoked when removing an entry. Unfortunately we don't add in the size for expiration (lifespan/maxidle). This can cause the count to think there are more bytes than there actually are, eventually evicting entries erroneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-7863) Ickle lexer wrongly discards letter v as whitespace ruining parsing of identifiers containing v
by Diego Lovison (Jira)
[ https://issues.jboss.org/browse/ISPN-7863?page=com.atlassian.jira.plugin.... ]
Diego Lovison updated ISPN-7863:
--------------------------------
Labels: on-hold (was: )
> Ickle lexer wrongly discards letter v as whitespace ruining parsing of identifiers containing v
> -----------------------------------------------------------------------------------------------
>
> Key: ISPN-7863
> URL: https://issues.jboss.org/browse/ISPN-7863
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 9.0.0.Final
> Reporter: Gregory Orciuch
> Assignee: Adrian Nistor
> Priority: Blocker
> Labels: on-hold
> Fix For: 9.4.0.Final, 9.3.4.Final
>
>
> Links to: https://issues.jboss.org/browse/ISPN-7861
> When quering ISPN server over hotrod and trying to access field which begins with "v" character that field access is lost but together with "group by" operator.
> Example of entity using proto/annotations:
> {code:java}
> @ProtoDoc("@Indexed")
> public class Offering implements Serializable {
> private String name;
> private Integer relationSetId;
> private Integer variant;
>
> @ProtoDoc("@Field(store = Store.YES, analyze = Analyze.YES)")
> @ProtoField(number = 5, required = true)
> public String getName() {
> return name;
> }
> public void setName(String name) {
> this.name = name;
> }
>
> @ProtoField(number = 44)
> public Integer getRelationSetId() {
> return relationSetId;
> }
> public void setRelationSetId(Integer relationSetId) {
> this.relationSetId = relationSetId;
> }
>
> @ProtoDoc("@Field(store = Store.YES, analyze = Analyze.NO)")
> @ProtoField(number = 50)
> public Integer getVariant() {
> return variant;
> }
> public void setVariant(Integer variant) {
> this.variant = variant;
> }
>
> }
> {code}
> Then executing query like this:
> {code:sql}
> select min(_gen0.name),min(_gen0.variant) FROM Offering _gen0 WHERE _gen0.variant = 44 GROUP BY _gen0.relationSetId
> {code}
> Produces server side error which mentions "ariant" - v - is lost. Paste is below.
> NOT using group by is causing that query to run well.
> ALSO Changing variable name from variant to "bariant" helps.
> LOOKS like there is some code which restricts the name or parses wrongly.
> Affects not only simple type fields but also List<Variant> variants - "v" is lost.
> {panel:title=log}
> 14:02:50,951 DEBUG [org.infinispan.query.dsl.embedded.impl.QueryEngine] (HotRod-ServerHandler-6-16) Building query 'select min(_gen0.name),min(_gen0.variant) FROM Offering _gen0 WHERE _gen0.variant = 44 GROUP BY _gen0.relationSetId' with parameters null
> 14:02:50,953 DEBUG [org.infinispan.server.hotrod.HotRodExceptionHandler] (HotRod-ServerWorker-4-1) Exception caught: org.infinispan.objectfilter.ParsingException: ISPN028501: The type Offering has no property named '*ariant*'.
> at org.infinispan.objectfilter.impl.syntax.parser.QueryResolverDelegateImpl.normalizeProperty(QueryResolverDelegateImpl.java:191)
> at org.infinispan.objectfilter.impl.syntax.parser.QueryResolverDelegateImpl.normalizeUnqualifiedPropertyReference(QueryResolverDelegateImpl.java:84)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.unqualifiedPropertyReference(QueryResolver.java:7651)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.propertyReferencePath(QueryResolver.java:7548)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.propertyReferenceExpression(QueryResolver.java:5689)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.valueExpressionPrimary(QueryResolver.java:5495)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.valueExpression(QueryResolver.java:5271)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.rowValueConstructor(QueryResolver.java:4490)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.predicate(QueryResolver.java:3326)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.searchCondition(QueryResolver.java:2979)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.whereClause(QueryResolver.java:655)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.querySpec(QueryResolver.java:510)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatement(QueryResolver.java:379)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatementSet(QueryResolver.java:292)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.statement(QueryResolver.java:220)
> at org.infinispan.objectfilter.impl.ql.QueryParser.resolve(QueryParser.java:81)
> at org.infinispan.objectfilter.impl.ql.QueryParser.parseQuery(QueryParser.java:69)
> at org.infinispan.objectfilter.impl.syntax.parser.IckleParser.parse(IckleParser.java:19)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.lambda$parse$1(QueryEngine.java:663)
> at org.infinispan.query.dsl.embedded.impl.QueryCache.lambda$get$0(QueryCache.java:79)
> at org.infinispan.cache.impl.TypeConverterDelegatingAdvancedCache.lambda$convertFunction$1(TypeConverterDelegatingAdvancedCache.java:101)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.infinispan.cache.impl.AbstractDelegatingCache.computeIfAbsent(AbstractDelegatingCache.java:343)
> at org.infinispan.cache.impl.TypeConverterDelegatingAdvancedCache.computeIfAbsent(TypeConverterDelegatingAdvancedCache.java:161)
> at org.infinispan.query.dsl.embedded.impl.QueryCache.get(QueryCache.java:79)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.parse(QueryEngine.java:663)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQueryWithAggregations(QueryEngine.java:299)
> at org.infinispan.query.dsl.embedded.impl.QueryEngine.buildQuery(QueryEngine.java:139)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.createQuery(DelegatingQuery.java:91)
> at org.infinispan.query.dsl.embedded.impl.DelegatingQuery.list(DelegatingQuery.java:98)
> at org.infinispan.query.remote.impl.QueryFacadeImpl.makeResponse(QueryFacadeImpl.java:61)
> at org.infinispan.query.remote.impl.QueryFacadeImpl.query(QueryFacadeImpl.java:53)
> at org.infinispan.server.hotrod.HotRodServer.query(HotRodServer.java:116)
> at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:148)
> at org.infinispan.server.hotrod.ContextHandler.lambda$null$0(ContextHandler.java:59)
> at org.infinispan.security.Security.doAs(Security.java:143)
> at org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$1(ContextHandler.java:58)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:748)
> {panel}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (ISPN-9535) Feature flags
by Diego Lovison (Jira)
[ https://issues.jboss.org/browse/ISPN-9535?page=com.atlassian.jira.plugin.... ]
Diego Lovison closed ISPN-9535.
-------------------------------
> Feature flags
> -------------
>
> Key: ISPN-9535
> URL: https://issues.jboss.org/browse/ISPN-9535
> Project: Infinispan
> Issue Type: Feature Request
> Components: Configuration
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 9.4.0.Final
>
>
> We need a way to enable/disable certain features using flags.
> The flags are properties in the form:
> org.infinispan.featurename
> any META-INF/infinispan-features.properties resources found on the classpath will be loaded and aggregated, and any property that is set to false will not be available.
> The Features object will be initialized by global configurations (GlobalConfigurationBuilder and Hot Rod ConfigurationBuilder) and can be queried in configuration builders' validate methods to decide whether features can be used or not.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months