[JBoss JIRA] (ISPN-10466) StateConsumerImpl.removeStaleData takes too long with unsegmented stores
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-10466?page=com.atlassian.jira.plugin... ]
Pedro Zapata Fernandez updated ISPN-10466:
------------------------------------------
Sprint: DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34 (was: DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35)
> StateConsumerImpl.removeStaleData takes too long with unsegmented stores
> ------------------------------------------------------------------------
>
> Key: ISPN-10466
> URL: https://issues.jboss.org/browse/ISPN-10466
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 9.4.16.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 9.4.17.Final
>
>
> With a segmented data container, {{removeStaleData}} is very fast. But the product doesn't use segmented data containers yet, so it's still important to make {{removeStaleData}} faster with unsegmented data containers.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[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 (was: DataGrid Sprint #30, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35)
> 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-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 (was: DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35)
> 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:
------------------------------------------
Fix Version/s: 10.1.0.Final
(was: 10.0.0.Final)
> 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.1.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-9865) Query is failing if custom classes are used inside of the cache
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-9865?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez updated ISPN-9865:
-----------------------------------------
Sprint: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34 (was: DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35)
> Query is failing if custom classes are used inside of the cache
> ---------------------------------------------------------------
>
> Key: ISPN-9865
> URL: https://issues.jboss.org/browse/ISPN-9865
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, WildFly modules
> Affects Versions: 9.4.5.Final
> Environment: Wildfly server with ISPN modules and ISPN subsystem to configure caches
> Reporter: Wolf-Dieter Fink
> Assignee: Nistor Adrian
> Priority: Major
> Attachments: install1-standalone-local.cli, install2-standalone-local.cli
>
>
> A simple query for a cache which contains User classes will fail for queries with the error below.
> UserData class for the cache:
> public class Test implements Serializable {
> private int testId;
> public Test(){}
> public Test(int myId) {this.testId = myId;}
> public int getTestId() {return animalId;}
> public void setTestId(int testId) { this.testId = testId;}
> }
> Simple EJB for test
> @Singleton
> @Startup
> public class TestInfinispanQuery4EAPConfig {
> @Resource(lookup = "java:jboss/datagrid-infinispan/container/jdg-container/cache/EAPcache")
> private Cache<String, Object> cache;
>
> @PostConstruct
> public void LoadDBToMemory() {
> cache.put("1", new Test(2, 0));
> cache.put("2", new Test(2, 0));
> cache.put("3", new Test(1, 0));
> QueryFactory queryFactory = Search.getQueryFactory(cache);
>
> Query q = queryFactory.from(Test.class).having("testId").eq(2).build();
>
> int size = q.getResultSize();
> System.out.println("result = " + size);
> }
> }
> Caused by: java.lang.IllegalStateException: ISPN028510: Unknown entity name org.infinispan.wfink.web.Test
> at org.infinispan.objectfilter.impl.syntax.parser.QueryResolverDelegateImpl.registerPersisterSpace(QueryResolverDelegateImpl.java:60)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.entityName(QueryResolver.java:6683)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.persisterSpaceRoot(QueryResolver.java:1302)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.persisterSpace(QueryResolver.java:1203)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.persisterSpaces(QueryResolver.java:1144)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.fromClause(QueryResolver.java:1060)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.selectFrom(QueryResolver.java:969)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.querySpec(QueryResolver.java:487)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatement(QueryResolver.java:388)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.queryStatementSet(QueryResolver.java:308)
> at org.infinispan.objectfilter.impl.ql.parse.QueryResolver.statement(QueryResolver.java:241)
> 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:695)
> at org.infinispan.query.dsl.embedded.impl.QueryCache.lambda$get$ab3121d1$1(QueryCache.java:73)
> at org.infinispan.compat.FunctionMapper.apply(FunctionMapper.java:40)
> at org.infinispan.commands.write.ComputeIfAbsentCommand.perform(ComputeIfAbsentCommand.java:104)
> at org.infinispan.interceptors.impl.CallInterceptor.visitCommand(CallInterceptor.java:29)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:100)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:672)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-9893) New Reactive API
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-9893?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez updated ISPN-9893:
-----------------------------------------
Sprint: DataGrid Sprint #29, DataGrid Sprint #30, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34 (was: DataGrid Sprint #29, DataGrid Sprint #30, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34, DataGrid Sprint #35)
> New Reactive API
> ----------------
>
> Key: ISPN-9893
> URL: https://issues.jboss.org/browse/ISPN-9893
> Project: Infinispan
> Issue Type: Enhancement
> Components: API
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> See sub-talks. This is an umbrella issue
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-9726) Document max clause property on boolean query
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-9726?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez updated ISPN-9726:
-----------------------------------------
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 (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)
> Document max clause property on boolean query
> ---------------------------------------------
>
> Key: ISPN-9726
> URL: https://issues.jboss.org/browse/ISPN-9726
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Affects Versions: 10.0.0.Alpha1
> Reporter: Katia Aresti
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.0.0.Final
>
>
> Document the ability to override org.apache.lucene.search.BooleanQuery.maxClauseCount using infinispan.query.lucene.max-boolean-clauses JVM system property.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (ISPN-9592) Lockdown query internals
by Pedro Zapata Fernandez (Jira)
[ https://issues.jboss.org/browse/ISPN-9592?page=com.atlassian.jira.plugin.... ]
Pedro Zapata Fernandez updated ISPN-9592:
-----------------------------------------
Fix Version/s: 11.0.0.Final
> Lockdown query internals
> ------------------------
>
> Key: ISPN-9592
> URL: https://issues.jboss.org/browse/ISPN-9592
> Project: Infinispan
> Issue Type: Task
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 11.0.0.Final
>
>
> Many things in query implementation are left public although they are very prone to creating insidious bugs if accessed externally. These are not proper extension points and should be made package local or provided strictly via SearchManagerImplementor.
> * Move SearchManager.purge(Class) method to SearchManagerImplementor
> * DefaultSearchWorkCreator should be moved to org.infinispan.query.backend and made package local
> * TransactionalEventTransactionContext is not used, can be removed, and its non-tx counterpart (NoTransactionContext) no longer has to be public
> * all public methods in QueryInterceptor must be reviewed and made package local ASAP
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months