[JBoss JIRA] (WFLY-10945) JDK11 ws testsuite SSL failures
by David Lloyd (Jira)
[ https://issues.jboss.org/browse/WFLY-10945?page=com.atlassian.jira.plugin... ]
David Lloyd commented on WFLY-10945:
------------------------------------
JDK 9 will load providers from the boot module or JAR with service loader. But that does not apply here. JBoss Modules will also load providers from the boot module given to it, so if this module is part of the boot module set, it will be loaded and installed. Finally, Elytron's authentication components have the capability to locate providers at run time via service loader, but without installing them globally. Whether this is done depends on configuration and also on what our defaults are (which I do not recall), and also (obviously) on whether the provider module is visible to the class loader on behalf of whom the service loading is being done.
> JDK11 ws testsuite SSL failures
> -------------------------------
>
> Key: WFLY-10945
> URL: https://issues.jboss.org/browse/WFLY-10945
> Project: WildFly
> Issue Type: Sub-task
> Components: Test Suite
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 15.0.0.Alpha1
>
>
> ws testsuite failures on JDK-11:
> * missing local IP in SubjectAlternativeNamesExtension
> * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + TLS1.2 seems buggy on JDK-11: Invalid ECDH ServerKeyExchange signature
> * not issue after switching to TLS1.1 or to ciphersuite TLS_RSA_WITH_AES_256_CBC_SHA256 -> JDK bug
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11129) Temporary files not cleaned up after build
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFLY-11129?page=com.atlassian.jira.plugin... ]
Yeray Borges resolved WFLY-11129.
---------------------------------
Fix Version/s: 15.0.0.Alpha1
Resolution: Done
Thanks for pointing it out [~aloubyansky], yes, effectively 2.0.1.Final version fixes the issue.
Hi [~lafr] thank you for reporting the issue, I don't think the environment it is related but if you still think it is reproducible in Solaris, please, feel free to reopen the ticket, thanks!
> Temporary files not cleaned up after build
> ------------------------------------------
>
> Key: WFLY-11129
> URL: https://issues.jboss.org/browse/WFLY-11129
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Affects Versions: 14.0.1.Final
> Environment: Solaris SPARC 10, Oracle JDK 1.80,0_181
> Reporter: Frank Langelage
> Assignee: Yeray Borges
> Priority: Major
> Labels: maven
> Fix For: 15.0.0.Alpha1
>
>
> After building WildFly 14 from sources I have a lot of files in /var/tmp folder under a unique folder.
> {{sb2000.[neu2l]/mbi/mbi2e_all. ls -l /var/tmp
> total 5356
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:47 1397ea75-a91c-490a-9860-0041c101ef3a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:47 23d28bb9-0bdd-4991-aa9b-8805d613e720
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:34 2c3bd18e-8b83-46d3-b06f-18378e1cb12d
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:56 396f75f7-45b0-4b50-9607-9060cabf018b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:48 521e2a76-764c-4f5a-8a6e-282dd5978991
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:35 5430e295-1afa-4257-a2e0-e08b980b7e35
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:53 5a265551-8f04-48c9-8945-abf830e54852
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:46 70a1f863-7e84-40df-9206-23690bcf3ef6
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:02 7186627a-5a89-4334-bdc2-8bfb944e3841
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:52 85663b19-7e4e-48e9-8988-bd24c11fe4d4
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:39 8842f374-85b7-4018-a1fc-6274cb704785
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:05 973d7e32-efe5-4ffa-8f02-079cb7f29e71
> drwxr-x--- 3 oracle dba 2560 Aug 30 00:00 CVU_18.0.0.0.0_oracle
> drwxr-xr-x 3 jboss informix 512 Oct 5 22:06 b8975817-9381-41a3-a512-e8fc6596fa7a
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:40 bd0c1dd7-e8c6-413d-b658-f3c5236bba34
> drwxr-xr-x 3 jboss informix 512 Oct 6 14:54 c3aa3f01-66df-4066-bb35-fed4bd0ad559
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:32 c66c2972-ad28-49e9-a7ff-a7ceed5b7ea3
> drwxr-xr-x 3 jboss informix 512 Oct 5 23:24 ca8816d8-ad10-4860-a18b-0c09b37ed88b
> drwxr-xr-x 3 jboss informix 512 Oct 6 13:50 cc799f82-ed02-4dc4-b56e-ffe0d8eeab75
> drwx------ 2 langfr staff 512 Nov 15 2006 orbit-lafr
> -rw-rw-rw- 1 langfr staff 2383862 Oct 5 03:17 patchdiag.xref
> -rw------- 1 root root 314461 Oct 6 15:32 wscon-:0-5saqic}}
> {{sb2000.[neu2l]/var/tmp. ls -l 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/*/current
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-core/current:
> total 2
> drwxr-xr-x 7 jboss informix 512 Oct 6 14:55 6.0.2.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly-servlet/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final
> 396f75f7-45b0-4b50-9607-9060cabf018b/maven/org.jboss.universe_community-universe/wildfly/current:
> total 2
> drwxr-xr-x 6 jboss informix 512 Oct 6 14:55 14.0.1.Final}}
> Created by galleon feature pack build (galleon-pack/wildfly-feature-pack-build.xml).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10464) ISPN000482: Cannot create remote transaction X, already completed in ASYM_ENCRYPT scenario (following "received message without encrypt header from perf21; dropping it")
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-10464?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-10464:
----------------------------------
Priority: Blocker (was: Critical)
> ISPN000482: Cannot create remote transaction X, already completed in ASYM_ENCRYPT scenario (following "received message without encrypt header from perf21; dropping it")
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10464
> URL: https://issues.jboss.org/browse/WFLY-10464
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 14.0.0.Final
> Reporter: Michal Vinkler
> Assignee: Radoslav Husar
> Priority: Blocker
>
> Affected scenario: eap-7x-failover-http-session-shutdown-dist-sync-auth-asymEncrypt (scenario with "AUTH" and "ASYM_ENCRYPT" protocols enabled).
> In server logs, we can see lots of WARN/ERROR messages logged.
> With 2000 clients, none of them is bound to a specific time/event (i.e. failover).
> When lowering number of clients to 10, Excpetion #1 starts occurring right after each failover, #2 + #3 occur after node rejoins the cluster.
> {code:title=#1 ISPN000482: Cannot create remote transaction X, already completed}
> [JBossINF] [0m[33m04:44:50,005 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (remote-thread--p5-t3) ISPN000071: Caught exception when handling command LockControlCommand{cache=clusterbench-ee7.ear.clusterbench-ee7-web-default.war, keys=[SessionCreationMetaDataKey(r6mU8aS9wDfsmP7rAJ1892KSrjgnmzoTRytiyrNt)], flags=[FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTx:perf21:49128}: org.infinispan.commons.CacheException: ISPN000482: Cannot create remote transaction GlobalTx:perf21:49128, already completed
> [JBossINF] at org.infinispan.transaction.impl.TransactionTable.lambda$getOrCreateRemoteTransaction$1(TransactionTable.java:375)
> [JBossINF] at java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1853)
> [JBossINF] at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:368)
> [JBossINF] at org.infinispan.transaction.impl.TransactionTable.getOrCreateRemoteTransaction(TransactionTable.java:348)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.createContext(LockControlCommand.java:139)
> [JBossINF] at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:122)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
> [JBossINF] at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> {code}
> {code:title=#2 ISPN000476: Timed out waiting for responses for request 47698 from X}
> [JBossINF] [0m[31m04:46:24,448 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (timeout-thread--p12-t1) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 47698 from perf21
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> {code}
> {code:title=#3 CIRCULAR REFERENCE -> UT005023: Exception handling request to /clusterbench/session: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 47460 from X}
> [JBossINF] [0m[31m04:46:24,053 ERROR [io.undertow.request] (default task-98) UT005023: Exception handling request to /clusterbench/session: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 47460 from perf21
> [JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:485)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:528)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
> [JBossINF] at org.infinispan.cache.impl.EncoderCache.get(EncoderCache.java:658)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:78)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:68)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:59)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:37)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:200)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:176)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:858)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:412)
> [JBossINF] at org.jboss.weld.module.web.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:241)
> [JBossINF] at org.jboss.weld.module.web.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF] Caused by: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 47460 from perf21
> [JBossINF] at org.infinispan.remoting.transport.impl.MultiTargetRequest.onTimeout(MultiTargetRequest.java:167)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:87)
> [JBossINF] at org.infinispan.remoting.transport.AbstractRequest.call(AbstractRequest.java:22)
> [JBossINF] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> [JBossINF] at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [JBossINF] ... 1 more
> [JBossINF] Suppressed: java.util.concurrent.ExecutionException: org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 47460 from perf21
> [JBossINF] at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357)
> [JBossINF] at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1915)
> [JBossINF] at org.infinispan.util.concurrent.CompletableFutures.await(CompletableFutures.java:82)
> [JBossINF] at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:37)
> [JBossINF] at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:250)
> [JBossINF] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:485)
> [JBossINF] at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:528)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
> [JBossINF] at org.infinispan.cache.impl.EncoderCache.get(EncoderCache.java:658)
> [JBossINF] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.getValue(InfinispanSessionMetaDataFactory.java:78)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:68)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionMetaDataFactory.findValue(InfinispanSessionMetaDataFactory.java:39)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:59)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionFactory.findValue(InfinispanSessionFactory.java:37)
> [JBossINF] at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:200)
> [JBossINF] at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:176)
> [JBossINF] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:858)
> [JBossINF] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:412)
> [JBossINF] at org.jboss.weld.module.web.servlet.SessionHolder.requestInitialized(SessionHolder.java:47)
> [JBossINF] at org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:241)
> [JBossINF] at org.jboss.weld.module.web.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
> [JBossINF] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1514)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] ... 1 more
> [JBossINF] [CIRCULAR REFERENCE:org.infinispan.util.concurrent.TimeoutException: ISPN000476: Timed out waiting for responses for request 47460 from perf21]
> {code}
> {code:title=#4 received message without encrypt header}
> [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it
> {code}
> Client gets valid responses till approx. 30 seconds after first failover, then Read timeouts start occuring. As far as I can tell, no valid response is received from this point.
> Link to server log - 2000 clients:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> Link to client log - 2000 clients:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> Link to server log - 10 clients:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
> Link to client log - 10 clients:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on JGRP-2297 at 10/8/18 1:01 PM:
---------------------------------------------------------------
Moreover, the non-coordinator seems to always leave the cluster problematically and is always accompanied by the following ERROR log line (in this case, node3 leaves the cluster with a view [node3, node1])
{code}18:57:38,468 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-14,ejb,node1) key requester node3 is not in current view [node1|6] (1) [node1]; ignoring key request{code}
I think the fix for both is the same, so probably does not need a specific Jira.
was (Author: rhusar):
Moreover, the non-coordinator seems to always leave the cluster problematically and is always acomanied by the following ERROR log line (in this case, node3 leaves the cluster with a view [node3, node1])
{code}18:57:38,468 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-14,ejb,node1) key requester node3 is not in current view [node1|6] (1) [node1]; ignoring key request{code}
I think the fix for both is the same, so probably does not need a specific Jira.
> Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
> --------------------------------------------------------------------
>
> Key: JGRP-2297
> URL: https://issues.jboss.org/browse/JGRP-2297
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.16
>
>
> The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3.
> Here is a run of the test with a modification of the test with a *single* coordinator leaving:
> https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db
> The problem seems to be with coordinating of key exchange. In this run, roughly:
> 1. node 1 is leaving
> 2. node 2 becomes coordinator and key server
> {noformat}
> 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10]
> ...
> 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> ...
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> {noformat}
> 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1?
> {noformat}
> 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> ...
> 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E)
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed
> {noformat}
> 4. new coordinator fails to collect all acks (since it cannot decipher stale key?)
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9
> {noformat}
> 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2
> 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> 6. cluster is later healed with MERGE3
> {noformat}
> 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
> {noformat}
> Another run with MERGE3 omitted from the stack is here:
> https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707
> Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT.
> Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on JGRP-2297 at 10/8/18 1:01 PM:
---------------------------------------------------------------
Moreover, the non-coordinator seems to always leave the cluster problematically as well and is always accompanied by the following ERROR log line (in this case, node3 leaves the cluster with a view [node1, node3])
{code}18:57:38,468 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-14,ejb,node1) key requester node3 is not in current view [node1|6] (1) [node1]; ignoring key request{code}
I think the fix for both is the same, so probably does not need a specific Jira.
was (Author: rhusar):
Moreover, the non-coordinator seems to always leave the cluster problematically and is always accompanied by the following ERROR log line (in this case, node3 leaves the cluster with a view [node3, node1])
{code}18:57:38,468 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-14,ejb,node1) key requester node3 is not in current view [node1|6] (1) [node1]; ignoring key request{code}
I think the fix for both is the same, so probably does not need a specific Jira.
> Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
> --------------------------------------------------------------------
>
> Key: JGRP-2297
> URL: https://issues.jboss.org/browse/JGRP-2297
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.16
>
>
> The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3.
> Here is a run of the test with a modification of the test with a *single* coordinator leaving:
> https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db
> The problem seems to be with coordinating of key exchange. In this run, roughly:
> 1. node 1 is leaving
> 2. node 2 becomes coordinator and key server
> {noformat}
> 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10]
> ...
> 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> ...
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> {noformat}
> 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1?
> {noformat}
> 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> ...
> 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E)
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed
> {noformat}
> 4. new coordinator fails to collect all acks (since it cannot decipher stale key?)
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9
> {noformat}
> 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2
> 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> 6. cluster is later healed with MERGE3
> {noformat}
> 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
> {noformat}
> Another run with MERGE3 omitted from the stack is here:
> https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707
> Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT.
> Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (JGRP-2297) Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/JGRP-2297?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on JGRP-2297:
--------------------------------------
Moreover, the non-coordinator seems to always leave the cluster problematically and is always acomanied by the following ERROR log line (in this case, node3 leaves the cluster with a view [node3, node1])
{code}18:57:38,468 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-14,ejb,node1) key requester node3 is not in current view [node1|6] (1) [node1]; ignoring key request{code}
I think the fix for both is the same, so probably does not need a specific Jira.
> Coordinator with ASYM_ENCRYPT in the stack does not leave gracefully
> --------------------------------------------------------------------
>
> Key: JGRP-2297
> URL: https://issues.jboss.org/browse/JGRP-2297
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.14
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 4.0.16
>
>
> The {{ASYM_ENCRYPT_LeaveTest}} is designed to test graceful leaving coordinator(s) with ASYM_ENCRYPT in the stack. However, the test currently passes due to presence of MERGE3 in the stack. While the intention of the test seems to be testing graceful leaving of coordinator(s), the cluster ends up with inconsistent views later resolved by MERGE3.
> Here is a run of the test with a modification of the test with a *single* coordinator leaving:
> https://gist.github.com/rhusar/89172882fae60a1f29327c33f2d124db
> The problem seems to be with coordinating of key exchange. In this run, roughly:
> 1. node 1 is leaving
> 2. node 2 becomes coordinator and key server
> {noformat}
> 10:55:18.286 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: installing view [2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10]
> ...
> 10:55:18.299 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: I'm the new key server
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> ...
> 10:55:18.300 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 2: created new secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> {noformat}
> 3. node 9 receives {{FETCH_SECRET_KEY}} however receives stale key? looks like it still contacts the leaving coordinator node 1?
> {noformat}
> 10:55:18.319 [SSL_KEY_EXCHANGE-runner-12,ASYM_ENCRYPT_LeaveTest,1] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 1: accepted SSL connection from /127.0.0.1:51812; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> ...
> 10:55:18.319 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2157); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AF7916A9394F49B085D4F35C4F5A0A3E)
> 10:55:18.321 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: ignoring secret key received from key exchange protocol (version: AF7916A9394F49B085D4F35C4F5A0A3E), as it has already been installed
> {noformat}
> 4. new coordinator fails to collect all acks (since it cannot decipher stale key?)
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,2] WARN org.jgroups.protocols.pbcast.GMS - 2: failed to collect all ACKs (expected=8) for view [2|10] after 2000ms, missing 1 ACKs from (1) 9
> {noformat}
> 5. node 9 eventually obtains the key but since it has stale view and still thinks node 1 is coordinator? and fails to contact it
> {noformat}
> 10:55:20.307 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: asking key exchange protocol to get secret key from 2
> 10:55:20.322 [SSL_KEY_EXCHANGE-runner-26,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 2: accepted SSL connection from /127.0.0.1:51829; protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: created SSL connection to 2 (/127.0.0.1:2158); protocol: TLSv1, cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.SSL_KEY_EXCHANGE - 9: sending up secret key (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:20.322 [jgroups-3,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.ASYM_ENCRYPT - 9: installing secret key received from key exchange protocol (version: AB1E6F44DE947D792A7D05D2E957AC85)
> 10:55:23.341 [TQ-Bundler-10,ASYM_ENCRYPT_LeaveTest,9] DEBUG org.jgroups.protocols.TCP - JGRP000034: 9: failure sending message to 1: java.net.ConnectException: Connection refused (Connection refused)
> {noformat}
> 6. cluster is later healed with MERGE3
> {noformat}
> 10:55:27.103 [jgroups-27,ASYM_ENCRYPT_LeaveTest,2] DEBUG org.jgroups.protocols.pbcast.GMS - 2: I will be the merge leader. Starting the merge task. Views: {2=[2|10] (9) [2, 3, 4, 5, 6, 7, 8, 9, 10], 9=[1|9] (10) [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]}
> {noformat}
> Another run with MERGE3 omitted from the stack is here:
> https://gist.github.com/rhusar/b51aeee03485a607041f9669bbc6e707
> Further investigation is ongoing, but this might be related to graceful leaving of coordinator JGRP-2293 exacerbating the problem with key exchange in ASYM_ENCRYPT.
> Scaling down is typical cloud workflow, especially with encryption since {{ASYM_ENCRYPT}} is the recommended setup making this problem critical.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-2996) Existing Rules are not working as expected after migrating the Drools version from 6.0.3 to 7.4.1.Final
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-2996?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-2996:
--------------------------------
Fix Version/s: 7.13.0.Final
> Existing Rules are not working as expected after migrating the Drools version from 6.0.3 to 7.4.1.Final
> -------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2996
> URL: https://issues.jboss.org/browse/DROOLS-2996
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.4.1.Final
> Reporter: Prameela Pod
> Assignee: Mario Fusco
> Priority: Major
> Fix For: 7.13.0.Final
>
> Attachments: DroolsTestPortlet.zip, logs.txt
>
>
> After drools migration from 6.0.3 to 7.4.1.Final version , modify property in 1st rule not validating conditions in 2nd rule.
> Ex: modify($alarm){setEVENTO_EN_TAREA("YES")} - In 1st rule then condition
> $alarm: ALARMA_ERICSSON_2G("NO" == getEVENTO_EN_TAREA()) - When condition in 2nd rule.
> If getEVENTO_EN_TAREA() = "YES" then only it should go inside 2nd rule.But here in this case getEVENTO_EN_TAREA()="YES" or "NO" - For both cases 2nd rule when condition is matched and going inside then condition.Which is wrong
> Please find the attached sample test project with logs.
> Kindly let me know additional information is required.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10945) JDK11 ws testsuite SSL failures
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-10945?page=com.atlassian.jira.plugin... ]
Martin Choma edited comment on WFLY-10945 at 10/8/18 12:41 PM:
---------------------------------------------------------------
Looking into modules/system/layers/base/org/bouncycastle/main and I see
* META-INF/services/java.security.Provider defined in bcprov-jdk15on-1.60.0.redhat-00001.jar
* this snippet in module.xml
{noformat}
<provides>
<service name="java.security.Provider">
<with-class name="org.bouncycastle.jce.provider.BouncyCastleProvider"/>
<with-class name="org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider"/>
</service>
</provides>
{noformat}
That mean BouncyCastle is registered in JDK9+ automatically on server. BecauseIn JDK9+ providers started to be loaded also with service loader mechanism. [~dmlloyd] Do I recall correctly?
was (Author: mchoma):
Looking into modules/system/layers/base/org/bouncycastle/main and I see
* META-INF/services/java.security.Provider defined in bcprov-jdk15on-1.60.0.redhat-00001.jar
* this snippet in module.xml
{noformat}
<provides>
<service name="java.security.Provider">
<with-class name="org.bouncycastle.jce.provider.BouncyCastleProvider"/>
<with-class name="org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider"/>
</service>
</provides>
{noformat}
That mean BouncyCastle is registered in JDK9+ automatically on server. BecauseIn JDK9+ providers started to be loaded also with service loader mechanism.
> JDK11 ws testsuite SSL failures
> -------------------------------
>
> Key: WFLY-10945
> URL: https://issues.jboss.org/browse/WFLY-10945
> Project: WildFly
> Issue Type: Sub-task
> Components: Test Suite
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 15.0.0.Alpha1
>
>
> ws testsuite failures on JDK-11:
> * missing local IP in SubjectAlternativeNamesExtension
> * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + TLS1.2 seems buggy on JDK-11: Invalid ECDH ServerKeyExchange signature
> * not issue after switching to TLS1.1 or to ciphersuite TLS_RSA_WITH_AES_256_CBC_SHA256 -> JDK bug
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-10945) JDK11 ws testsuite SSL failures
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFLY-10945?page=com.atlassian.jira.plugin... ]
Martin Choma commented on WFLY-10945:
-------------------------------------
Looking into modules/system/layers/base/org/bouncycastle/main and I see
* META-INF/services/java.security.Provider defined in bcprov-jdk15on-1.60.0.redhat-00001.jar
* this snippet in module.xml
{noformat}
<provides>
<service name="java.security.Provider">
<with-class name="org.bouncycastle.jce.provider.BouncyCastleProvider"/>
<with-class name="org.bouncycastle.pqc.jcajce.provider.BouncyCastlePQCProvider"/>
</service>
</provides>
{noformat}
That mean BouncyCastle is registered in JDK9+ automatically on server. BecauseIn JDK9+ providers started to be loaded also with service loader mechanism.
> JDK11 ws testsuite SSL failures
> -------------------------------
>
> Key: WFLY-10945
> URL: https://issues.jboss.org/browse/WFLY-10945
> Project: WildFly
> Issue Type: Sub-task
> Components: Test Suite
> Affects Versions: 14.0.0.Beta2
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 15.0.0.Alpha1
>
>
> ws testsuite failures on JDK-11:
> * missing local IP in SubjectAlternativeNamesExtension
> * TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 + TLS1.2 seems buggy on JDK-11: Invalid ECDH ServerKeyExchange signature
> * not issue after switching to TLS1.1 or to ciphersuite TLS_RSA_WITH_AES_256_CBC_SHA256 -> JDK bug
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months