[Red Hat JIRA] (WFLY-13924) HTTP2 is not working with Oracle JDK8 u261
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-13924?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFLY-13924:
---------------------------------------
This have been fixed with WildFly Core upgrade. Output I'm getting with WildFly commit id fa68fad0acc746fd3cd669d75710a9e9455c3bc4 :
---
curl -k https://localhost:8443 -vvv >/dev/null
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying ::1:8443...
* connect to ::1 port 8443 failed: Connection refused
* Trying 127.0.0.1:8443...
* Connected to localhost (127.0.0.1) port 8443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [94 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [694 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=localhost
* start date: Oct 13 13:47:51 2020 GMT
* expire date: Oct 11 13:47:51 2030 GMT
* issuer: CN=localhost
* SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x5644a0de8b10)
} [5 bytes data]
> GET / HTTP/2
> Host: localhost:8443
> user-agent: curl/7.69.1
> accept: */*
>
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
} [5 bytes data]
< HTTP/2 200
< last-modified: Tue, 13 Oct 2020 13:44:18 GMT
< content-length: 1504
< content-type: text/html
< accept-ranges: bytes
< date: Tue, 13 Oct 2020 13:47:52 GMT
<
{ [1504 bytes data]
100 1504 100 1504 0 0 5063 0 --:--:-- --:--:-- --:--:-- 5063
* Connection #0 to host localhost left intact
---
> HTTP2 is not working with Oracle JDK8 u261
> ------------------------------------------
>
> Key: WFLY-13924
> URL: https://issues.redhat.com/browse/WFLY-13924
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 20.0.0.Final, 20.0.1.Final, 21.0.0.Beta1
> Reporter: Jan Stourac
> Assignee: Flavia Rainone
> Priority: Blocker
> Fix For: 21.0.0.Final
>
>
> There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since {{20.0.0.Final}} version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1.
> There is no such issue when I use {{WildFly 19.0.0.Final}}. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.
> This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726.
> There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed).
> *What is the issue here:*
> This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (WFLY-13956) TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-13956?page=com.atlassian.jira.plugi... ]
Tomasz Adamski edited comment on WFLY-13956 at 10/13/20 8:05 AM:
-----------------------------------------------------------------
[~cfang] I think I was able to reproduce TwoConnectorsEJBFailoverTestCase locally - though it requires a lot of repetitions before the test finally hangs. What is more I wasn't able to reproduce is with EJBCLIENT-356 commit reverted and was able to reproduce it with EJBCLIENT-376 reverted, which would confirm our initial suspicion that EJBCLIENT-356 is a culprit.
I was able to plug with debug to maven thread and saw that it is stuck waiting on awaitResponse, but I wasn't able to find out yet what happened to the two nodes that lead to this situation. I'm suspecting that there is some discovery bug when dealing with starting/stopping nodes after introduction of eagerNodes list to RemotingEJBDiscoveryProvider but I don't know yet what is the exact failure scenario.
The stacktrace of hanging thread:
{code:java}
"main@1" prio=5 tid=0x1 nid=NA waiting"main@1" prio=5 tid=0x1 nid=NA waiting java.lang.Thread.State: WAITING at java.lang.Object.wait(Object.java:-1) at java.lang.Object.wait(Object.java:502) at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:940) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:191) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:125) at com.sun.proxy.$Proxy30.increment(Unknown Source:-1) at org.jboss.as.test.clustering.cluster.ejb.remote.TwoConnectorsEJBFailoverTestCase.test(TwoConnectorsEJBFailoverTestCase.java:161) at org.jboss.as.test.clustering.cluster.ejb.remote.TwoConnectorsEJBFailoverTestCase.testEJBClientUsingHttpUpgradeProtocol(TwoConnectorsEJBFailoverTestCase.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.jboss.arquillian.junit.Arquillian$8$1.invokeMethod(Arquillian.java:325) at org.jboss.arquillian.junit.MethodInvoker$1.invoke(MethodInvoker.java:18) at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:57) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62) at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:50) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:118) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:139) at org.jboss.arquillian.junit.MethodInvoker.invoke(MethodInvoker.java:15) at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:332) at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:204) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:215) at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:279) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:88) at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:66) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128) at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116) at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86) at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133) at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105) at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159) at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:273) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166) at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350) at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54) at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345) at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418) {code}
was (Author: tomekadamski):
[~cfang] I think I was able to reproduce TwoConnectorsEJBFailoverTestCase locally - though it requires a lot of repetitions before the test finally hangs. What is more I wasn't able to reproduce is with EJBCLIENT-356 commit reverted and was able to reproduce it with EJBCLIENT-376 reverted, which would confirm our initial suspicion that EJBCLIENT-356 is a culprit.
I was able to plug with debug to maven thread and saw that it is stuck waiting on awaitResponse, but I wasn't able to find out yet what happened to the two nodes that lead to this situation. I'm suspecting that there is some discovery bug when dealing with starting/stopping nodes after introduction of eagerNodes list to RemotingEJBDiscoveryProvider but I don't know yet what is the exact failure scenario.
> TwoConnectorsEJBFailoverTestCase sometimes hangs when running with jboss-ejb-client 4.0.35
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-13956
> URL: https://issues.redhat.com/browse/WFLY-13956
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Attachments: Screen Shot 2020-10-12 at 9.57.36 AM.png
>
>
> When upgrading jboss-ejb-client to version 4.0.35.Final, we noticed some WildFly CI jobs sometimes hang when running {{TwoConnectorsEJBFailoverTestCase}}, causing 100+ (e.g., 466) tests to fail:
> {code}
> RemoteElytronSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteElytronSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testSessionTimeoutDestroysSSOorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testFormAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> RemoteSingleSignOnTestCase.testNoAuthSingleSignOnorg.jboss.as.test.clustering.cluster.sso.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodPersistenceWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodSessionActivationTestCase.testorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testNonPrimaryOwnerorg.jboss.as.test.clustering.cluster.web.remote
> CoarseTransactionalHotRodWebFailoverTestCase.testGracefulSimpleFailoverorg.jboss.as.test.clustering.cluster.web.remote
> FineHotRodPersistenceWebFailoverTestCase.testGracefulUndeployFailoverorg.jboss.as.test.clustering.cluster.web.remote
> {code}
> The error messages are like:
> {code}
> org.jboss.arquillian.container.spi.client.container.LifecycleException: The port 9990 is already in use. It means that either the server might be already running or there is another process using port 9990.
> Managed containers do not support connecting to running server instances due to the possible harmful effect of connecting to the wrong server.
> Please stop server (or another process) before running, change to another type of container (e.g. remote) or use jboss.socket.binding.port-offset variable to change the default port.
> To disable this check and allow Arquillian to connect to a running server, set allowConnectingToRunningServer to true in the container configuration
> {code}
> In a [successful CI job|https://ci.wildfly.org/buildConfiguration/WFPR/226438?], {{TwoConnectorsEJBFailoverTestCase}} runs 2 tests: {{testEJBClientUsingLegacyRemotingProtocol}} and {{testEJBClientUsingHttpUpgradeProtocol}}, each taking ~25 seconds to complete. See attached screenshot.
> But in a [failed CI job|https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/2...], filtering by {{TwoConnectorsEJBFailoverTestCase}} gives no result, which means the test hangs at {{testEJBClientUsingLegacyRemotingProtocol}} and so the test runner hasn't been able to collect the result from either test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JGRP-2430) GossipRouter: more efficient routing
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2430:
--------------------------------
Hmm, Java currently has no method to efficiently (natively) transfer data from an InputStream to an OutputStream, or from one SocketChannel to another...
In both cases, there's only a method to transfer to/from a FileInput/OutputStream or FileChannel.
This throws a wrench in my plans above, but let's see if we can still make GR a bit more efficient...
> GossipRouter: more efficient routing
> ------------------------------------
>
> Key: JGRP-2430
> URL: https://issues.redhat.com/browse/JGRP-2430
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
> It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[Red Hat JIRA] (JGRP-2430) GossipRouter: more efficient routing
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2430:
--------------------------------
On a closer look, this is *not* an issue: the secret key is the same at all members, so the GossipRouter does not need to decrypt/encrypt a message when routing it to its destination. The destination B has the same secret key as A, and will therefore be able to decrypt a message encrypted by A.
> GossipRouter: more efficient routing
> ------------------------------------
>
> Key: JGRP-2430
> URL: https://issues.redhat.com/browse/JGRP-2430
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.1
>
>
> GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address.
> It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages.
> Also look into routing of entire message _batches_.
> Investigate whether this is possible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months