August 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-10524) Failed to parse jboss-cli.xml

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10524?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10524: ----------------------------------- Security: (was: Red Hat Internal) > Failed to parse jboss-cli.xml > ----------------------------- > > Key: ISPN-10524 > URL: https://issues.jboss.org/browse/ISPN-10524 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.16.Final, 10.0.0.CR1 > Environment: > Reporter: Patrick Del Bello > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.CR2, 9.4.17.Final > > > Can't use ssl + vault > In order to avoid manually interaction of accepting certificates, it is better to configure a truststore at the clientside and then store the server's certificate in it, so using the following approach doesn't work with JBoss CLI. > Note that both RHDG and EAP, in this case, have the same VaultTool version. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10524) Failed to parse jboss-cli.xml

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10524?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10524: ----------------------------------- Status: Open (was: New) > Failed to parse jboss-cli.xml > ----------------------------- > > Key: ISPN-10524 > URL: https://issues.jboss.org/browse/ISPN-10524 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.16.Final, 10.0.0.CR1 > Environment: > Reporter: Patrick Del Bello > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.CR2, 9.4.17.Final > > > Can't use ssl + vault > In order to avoid manually interaction of accepting certificates, it is better to configure a truststore at the clientside and then store the server's certificate in it, so using the following approach doesn't work with JBoss CLI. > Note that both RHDG and EAP, in this case, have the same VaultTool version. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10512) ServerNG Docs: Connecting via CLI or Admin Console

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10512?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10512: ------------------------------- Sprint: DataGrid Sprint #34 (was: DataGrid Sprint #33) > ServerNG Docs: Connecting via CLI or Admin Console > -------------------------------------------------- > > Key: ISPN-10512 > URL: https://issues.jboss.org/browse/ISPN-10512 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Servers > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > As a user, I need to connect to remote server instances via the CLI or Admin Console. > As a user, I need to find CLI help text and understand basic command syntax. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10513) ServerNG Docs: Monitoring

by Donald Naro (Jira)

[ https://issues.jboss.org/browse/ISPN-10513?page=com.atlassian.jira.plugin... ] Donald Naro updated ISPN-10513: ------------------------------- Sprint: DataGrid Sprint #34 (was: DataGrid Sprint #33) > ServerNG Docs: Monitoring > ------------------------- > > Key: ISPN-10513 > URL: https://issues.jboss.org/browse/ISPN-10513 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Servers > Reporter: Donald Naro > Assignee: Donald Naro > Priority: Major > > As an admin, I need to monitor servers and gather statistics for performance and troubleshooting. > As an admin, I need to view log files and configure logging levels. > As an admin, I need to gather statistics and perform remote operations via JMX. > As an admin, I want to enable Prometheus monitoring. > As an admin, I want to retrieve server health from the REST endpoint. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8394) PendingLockManager blocks the caller thread if local

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-8394?page=com.atlassian.jira.plugin.... ] Pedro Ruivo closed ISPN-8394. ----------------------------- Resolution: Duplicate Issue > PendingLockManager blocks the caller thread if local > ---------------------------------------------------- > > Key: ISPN-8394 > URL: https://issues.jboss.org/browse/ISPN-8394 > Project: Infinispan > Issue Type: Enhancement > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > > The PendingLockManager is used when topology changes by transactional caches. It contains all the keys locked by transaction from previous topology id. > Current implementation blocks for local commands. This is problematic for pessimistic transaction because the lock is acquired during the runtime. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 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 Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10367?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10367: ------------------------------- Sprint: DataGrid Sprint #33 > 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.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10192) Non-blocking cross-site requests

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10192?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10192: ------------------------------- Fix Version/s: 10.0.0.Final > Non-blocking cross-site requests > -------------------------------- > > Key: ISPN-10192 > URL: https://issues.jboss.org/browse/ISPN-10192 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Final > > > Current implementation blocks the command in the interceptor chain waiting for it to be replicated to the remote site. This should be changed to a non-blocking approach. > Returning an {{InvocationStage}} should solve the issue. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10192) Non-blocking cross-site requests

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10192?page=com.atlassian.jira.plugin... ] Pedro Ruivo updated ISPN-10192: ------------------------------- Sprint: DataGrid Sprint #33 > Non-blocking cross-site requests > -------------------------------- > > Key: ISPN-10192 > URL: https://issues.jboss.org/browse/ISPN-10192 > Project: Infinispan > Issue Type: Enhancement > Components: Cross-Site Replication > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > > Current implementation blocks the command in the interceptor chain waiting for it to be replicated to the remote site. This should be changed to a non-blocking approach. > Returning an {{InvocationStage}} should solve the issue. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10495) Remove protobuf and protoparser dependencies

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-10495?page=com.atlassian.jira.plugin... ] Pedro Ruivo closed ISPN-10495. ------------------------------ > Remove protobuf and protoparser dependencies > -------------------------------------------- > > Key: ISPN-10495 > URL: https://issues.jboss.org/browse/ISPN-10495 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 10.0.0.Beta5, 9.4.16.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.CR1, 9.4.17.Final > > > Remove protobuf and protoparser dependencies. They aren't used. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9397) Check TX support for remote caches

by Pedro Ruivo (Jira)

[ https://issues.jboss.org/browse/ISPN-9397?page=com.atlassian.jira.plugin.... ] Pedro Ruivo closed ISPN-9397. ----------------------------- > Check TX support for remote caches > ---------------------------------- > > Key: ISPN-9397 > URL: https://issues.jboss.org/browse/ISPN-9397 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod, Remote Protocols, Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Beta4, 10.0.0.Final > > > The {{RemoteCacheManager.getCache()}} methods would fail to return a transactional cache if the cache in server isn't transactional. It would throw an exception! {{NotTransactionalException}}? > The user can fallback to the non transaction case, example > {code:java} > try { > cache = remoteCacheManager.getCache("some-cache", TransactionMode.NON_XA); > } catch(NotTransactionalException e) { > cache = remoteCacheManager.getCache("some-cache", TransactionMode.NONE); > } > {code} > In addition, some helper method can be added to the {{RemoteCacheManager}} to avoid dealing with exceptions: > {code:java} > boolean supportsTransactions(String cacheName); > {code} > simple example: > {code:java} > boolean txCache = remoteCacheManager.supportsTransactions("some-cache"); > remoteCacheManager.getCache("some-cache", txCache ? TransactionMode.NON_XA : TransactionMode.NONE); > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2019