October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10805) Coarse-grained logging for the Hot Rod client

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10805?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10805: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Coarse-grained logging for the Hot Rod client > --------------------------------------------- > > Key: ISPN-10805 > URL: https://issues.jboss.org/browse/ISPN-10805 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Affects Versions: 10.0.0.CR3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Final > > > INFO, WARN, ERROR and FATAL logs should use the org.infinispan.HOTROD category -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[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, DataGrid Sprint #36 (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 > Fix For: 10.1.0.Final > > 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, 5 months

1
0
0 / 0

[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, DataGrid Sprint #36 (was: DataGrid Sprint #29, DataGrid Sprint #30, DataGrid Sprint #31, DataGrid Sprint #32, DataGrid Sprint #33, DataGrid Sprint #34) > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10781) Expose ComponentRef.isAlias()

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10781?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10781: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > Expose ComponentRef.isAlias() > ----------------------------- > > Key: ISPN-10781 > URL: https://issues.jboss.org/browse/ISPN-10781 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Nistor Adrian > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Final > > > This will help distinguish ComponentRefs whenever we need too. For example JMX registration currently fails (and sadly, the error is hidden due to other problems) because of CacheJmxRegistration attempting to create MBeans twice for the Cache because it encounters two ComponentRefs when scanning the registry. Would be good to know which one is just an alias and ignore it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10797) DefaultCacheManager.startCache(String cacheName) does not actually start it if it's stopped

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10797?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10797: ------------------------------------------ Sprint: DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #35) > DefaultCacheManager.startCache(String cacheName) does not actually start it if it's stopped > ------------------------------------------------------------------------------------------- > > Key: ISPN-10797 > URL: https://issues.jboss.org/browse/ISPN-10797 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.0.0.Final > > > This method seems to start it properly if it was never running. But not if it was running at some point and now the cache is in terminated state due to stop(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10599) Jenkins pipeline for build and release operator

by Pedro Zapata Fernandez (Jira)

[ https://issues.jboss.org/browse/ISPN-10599?page=com.atlassian.jira.plugin... ] Pedro Zapata Fernandez updated ISPN-10599: ------------------------------------------ Sprint: DataGrid Sprint #34, DataGrid Sprint #35, DataGrid Sprint #36 (was: DataGrid Sprint #34, DataGrid Sprint #35) > Jenkins pipeline for build and release operator > ----------------------------------------------- > > Key: ISPN-10599 > URL: https://issues.jboss.org/browse/ISPN-10599 > Project: Infinispan > Issue Type: Feature Request > Components: Operator > Reporter: Vittorio Rigamonti > Assignee: Vittorio Rigamonti > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10859) Change site status only after failures

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-10859: ---------------------------------- Summary: Change site status only after failures Key: ISPN-10859 URL: https://issues.jboss.org/browse/ISPN-10859 Project: Infinispan Issue Type: Enhancement Components: Cross-Site Replication Affects Versions: 9.4.16.Final, 10.0.0.CR3 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Currently, the site status is checked and updates before sending each write request. However, it would be better to update the site's status only after a failure. If the cluster becomes idle and the last cross-site requests fail, the site will be taken offline. Changing this, will keep the site online and only updates the status after it sent the request. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10803) Use WildFly OpenSSL

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10803?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10803: ----------------------------------- Fix Version/s: 10.1.0.Final > Use WildFly OpenSSL > ------------------- > > Key: ISPN-10803 > URL: https://issues.jboss.org/browse/ISPN-10803 > Project: Infinispan > Issue Type: Enhancement > Components: Security, Server > Affects Versions: 10.0.0.CR3 > Reporter: Tristan Tarrant > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.1.0.Final > > > We currently use Netty's tcnative bits to enable native openssl. We should use WildFly OpenSSL instead since the work of productizing the native bits is done for us > https://github.com/wildfly/wildfly-openssl -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10858) Fix Spring Integration in Remote

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10858?page=com.atlassian.jira.plugin... ] Katia Aresti reassigned ISPN-10858: ----------------------------------- Assignee: Katia Aresti > Fix Spring Integration in Remote > -------------------------------- > > Key: ISPN-10858 > URL: https://issues.jboss.org/browse/ISPN-10858 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 10.0.0.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Critical > > The spring integration in remote needs to add to the white list the `org.infinispan.spring.common.provider.NullValue` class to work properly -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10858) Fix Spring Integration in Remote

by Katia Aresti (Jira)

[ https://issues.jboss.org/browse/ISPN-10858?page=com.atlassian.jira.plugin... ] Work on ISPN-10858 started by Katia Aresti. ------------------------------------------- > Fix Spring Integration in Remote > -------------------------------- > > Key: ISPN-10858 > URL: https://issues.jboss.org/browse/ISPN-10858 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 10.0.0.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Critical > > The spring integration in remote needs to add to the white list the `org.infinispan.spring.common.provider.NullValue` class to work properly -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2019