[JBoss JIRA] (ISPN-10024) Long test killer doesn't work on Java 11
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10024?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10024:
--------------------------------
Status: Open (was: New)
> Long test killer doesn't work on Java 11
> ----------------------------------------
>
> Key: ISPN-10024
> URL: https://issues.jboss.org/browse/ISPN-10024
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.4.8.Final, 10.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta3
>
>
> When a test takes > 5 minutes, {{RunningTestsRegistry}} takes a thread dump of the entire JVM and its child processes, then interrupts the test thread, and if the test still doesn't stop, it kills the test suite JVM.
> With OpenJDK 11, the path to {{jstack}} is wrong, the thread dump step fails, and the interrupt/kill steps are skipped.
> Note that on IBM JDK 8 {{jstack}} is missing completely, so we may want to write the thread stacktraces ourselves. The downside is that we would lose synchronization/lock/deadlock information.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-10024) Long test killer doesn't work on Java 11
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10024?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10024:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/6765
> Long test killer doesn't work on Java 11
> ----------------------------------------
>
> Key: ISPN-10024
> URL: https://issues.jboss.org/browse/ISPN-10024
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.4.8.Final, 10.0.0.Beta2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.Beta3
>
>
> When a test takes > 5 minutes, {{RunningTestsRegistry}} takes a thread dump of the entire JVM and its child processes, then interrupts the test thread, and if the test still doesn't stop, it kills the test suite JVM.
> With OpenJDK 11, the path to {{jstack}} is wrong, the thread dump step fails, and the interrupt/kill steps are skipped.
> Note that on IBM JDK 8 {{jstack}} is missing completely, so we may want to write the thread stacktraces ourselves. The downside is that we would lose synchronization/lock/deadlock information.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-10054) Remove Tree
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-10054:
--------------------------------------
Summary: Remove Tree
Key: ISPN-10054
URL: https://issues.jboss.org/browse/ISPN-10054
Project: Infinispan
Issue Type: Sub-task
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 10.0.0.Final
The Tree module is unsupported and has many issues. It should finally be removed.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-10053) Enable authenticated cache access
by Vittorio Rigamonti (Jira)
Vittorio Rigamonti created ISPN-10053:
-----------------------------------------
Summary: Enable authenticated cache access
Key: ISPN-10053
URL: https://issues.jboss.org/browse/ISPN-10053
Project: Infinispan
Issue Type: Feature Request
Components: Operator
Reporter: Vittorio Rigamonti
Assignee: Vittorio Rigamonti
Operator must allow the user to configure authenticated access to the cache with user, password and role.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-10050) unlock for fqn does not work while two udp packet received
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10050?page=com.atlassian.jira.plugin... ]
Dan Berindei commented on ISPN-10050:
-------------------------------------
Infinispan relies on JGroups UNICASTx and NAKACKx protocols to provide reliability, and they ignore duplicate UDP packets.
Unfortunately the tree module isn't properly maintained, and we don't investigate bugs in old versions either. Maybe you can reproduce it with 9.4.9.Final?
> unlock for fqn does not work while two udp packet received
> ----------------------------------------------------------
>
> Key: ISPN-10050
> URL: https://issues.jboss.org/browse/ISPN-10050
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 7.2.5.Final
> Reporter: 俐佳 张
> Priority: Minor
> Labels: lock
> Attachments: t783, t785
>
>
> when udp packet received twice, two threads try to acquire the lock, lock was acquired successfully twice. But unlock only executed ones. That cause fqn couldn't be released.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years
[JBoss JIRA] (ISPN-9761) Cannot wire or start components while the registry is not running
by Thomas Mortagne (Jira)
[ https://issues.jboss.org/browse/ISPN-9761?page=com.atlassian.jira.plugin.... ]
Thomas Mortagne commented on ISPN-9761:
---------------------------------------
Just got the same exception but with a different stack trace on Infinispan 9.4.9 but cannot reliably reproduce it:
{noformat}
19:04:34.070 [expiration-thread--p21-t1] WARN o.i.e.impl.ExpirationManagerImpl - ISPN000026: Caught exception purging data container!
org.infinispan.IllegalLifecycleStateException: Cannot wire or start components while the registry is not running
at org.infinispan.factories.impl.BasicComponentRegistryImpl.prepareWrapperChange(BasicComponentRegistryImpl.java:610)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:158)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.wire(BasicComponentRegistryImpl.java:736)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:712)
at org.infinispan.expiration.impl.ExpirationManagerImpl.processExpiration(ExpirationManagerImpl.java:94)
at org.infinispan.expiration.impl.ExpirationManagerImpl$ScheduledTask.run(ExpirationManagerImpl.java:245)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
This happen during an integration test which force a cache expiration wakeup interval or 100 (milliseconds) if that helps (maybe some race condition cause by such a low interval). I just upgraded from 8.2.11 in which I never saw this error.
> Cannot wire or start components while the registry is not running
> ------------------------------------------------------------------
>
> Key: ISPN-9761
> URL: https://issues.jboss.org/browse/ISPN-9761
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.1.Final
> Reporter: Radoslav Husar
> Assignee: Dan Berindei
> Priority: Major
>
> Looks like yet another clean shutdown issue surfaced after we changed WFLY-11324 to avoid some graceful shutdown bugs with the XA transaction table.
> {noformat}
> 16:28:38,874 ERROR [org.infinispan.commons.tx.TransactionImpl] (default task-2) ISPN000926: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=[node-1, node-2], isMarkedForRollback=false, lockedKeys=[], backupKeyLocks=[SessionAccessMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionCreationMetaDataKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5), SessionAttributesKey(2sYbjnFh2n-m_gkaOP2iz53e0ms4cbuARoeIdYJ5)], topologyId=5, stateTransferFlag=null} org.infinispan.transaction.synchronization.SyncLocalTransaction@72} org.infinispan.transaction.synchronization.SynchronizationAdapter@91: org.infinispan.IllegalLifecycleStateException: Cannot wire or start components while the registry is not running
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.prepareWrapperChange(BasicComponentRegistryImpl.java:610)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:158)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.wire(BasicComponentRegistryImpl.java:736)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:712)
> at org.infinispan.transaction.impl.TransactionCoordinator.commit(TransactionCoordinator.java:148)
> at org.infinispan.transaction.impl.TransactionTable.afterCompletion(TransactionTable.java:861)
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:33)
> at org.infinispan.commons.tx.TransactionImpl.notifyAfterCompletion(TransactionImpl.java:506)
> at org.infinispan.commons.tx.TransactionImpl.runCommit(TransactionImpl.java:338)
> at org.infinispan.commons.tx.TransactionImpl.commit(TransactionImpl.java:110)
> at org.wildfly.clustering.ee.infinispan.InfinispanBatch.close(InfinispanBatch.java:97)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.requestDone(DistributableSession.java:87)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:945)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:579)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:346)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years