[Red Hat JIRA] (DROOLS-5641) Compilation fails when chaining methods with function calls as params
by Ciprian Chiru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5641?page=com.atlassian.jira.plug... ]
Ciprian Chiru commented on DROOLS-5641:
---------------------------------------
For any additional questions related to this bug report, please address [~erikwiklander]
> Compilation fails when chaining methods with function calls as params
> ---------------------------------------------------------------------
>
> Key: DROOLS-5641
> URL: https://issues.redhat.com/browse/DROOLS-5641
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.43.0.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> Given the following rule:
> {code:java}
> global java.util.Set controlSet;
> global org.example.drools.service.DummyService dummyService;
> declare A
> x: String
> end
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> $m: Measurement( id == "color", $colorVal : val )
> $a: A()
> String() from dummyService.dummy($m.getSomethingBy($a.x), $a)
> then
> controlSet.add($colorVal);
> end{code}
>
> The compilation fails with:
> {code:java}
> [...]/target/generated-sources/drools-model-compiler/main/java/rules/Rules7ad4e52deb9d4184b7d7e4646c172273RuleMethods0.java:[27,111] no suitable method found for from(org.drools.model.Global<org.example.drools.service.DummyService>,org.drools.model.Variable<rules.A>,org.drools.model.Variable<org.example.drools.model.Measurement>,rules.P45.LambdaExtractor4580D2619F79AA1C0CC3F15809293690)
> [ERROR] method org.drools.model.DSL.<T>from(T) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.functions.Function0<T>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<T>from(org.drools.model.Variable<T>,org.drools.model.functions.Function1<T,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) T
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.functions.Function2<A,B,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B,C>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.functions.Function3<A,B,C,?>) is not applicable
> [ERROR] (inference variable B has incompatible equality constraints org.example.drools.model.Measurement,rules.A)
> [ERROR] method org.drools.model.DSL.<A,B,C,D>from(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.Variable<C>,org.drools.model.Variable<D>,org.drools.model.functions.Function4<A,B,C,D,?>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,C,D
> [ERROR] (actual and formal argument lists differ in length)){code}
>
> This error is reproducible with the latest _7.44.0-SNAPSHOT_ .
> The parameters are flipped between the LambdaExtractor and the RuleMethods generated classes.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5666) Cannot use date literals with the compiled model
by Ciprian Chiru (Jira)
[ https://issues.redhat.com/browse/DROOLS-5666?page=com.atlassian.jira.plug... ]
Ciprian Chiru commented on DROOLS-5666:
---------------------------------------
For any additional questions related to this bug report, please address [~erikwiklander] .
> Cannot use date literals with the compiled model
> ------------------------------------------------
>
> Key: DROOLS-5666
> URL: https://issues.redhat.com/browse/DROOLS-5666
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.43.1.Final
> Reporter: Ciprian Chiru
> Assignee: Luca Molteni
> Priority: Major
>
> as per [https://docs.jboss.org/drools/release/7.43.1.Final/drools-docs/html_singl... given the rule:
>
> {code:java}
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> Measurement( date > "01-May-1990", $colorVal : val )
> then
> controlSet.add($colorVal);
> end{code}
> should work.
> Instead it throws:
> {code:java}
> [...]/target/generated-sources/drools-model-compiler/main/java/rules/Rules54254744800a44aa8e98a0deb3d63bb0RuleMethods0.java:[26,159] method alphaIndexedBy in class org.drools.model.PatternDSL cannot be applied to given types;
> [ERROR] required: java.lang.Class<U>,org.drools.model.Index.ConstraintType,int,org.drools.model.functions.Function1<T,U>,U
> [ERROR] found: java.lang.Class<java.time.LocalDate>,org.drools.model.Index.ConstraintType,int,rules.P33.LambdaExtractor33FA9B82326DE87BF650FB57D8DB8143,java.lang.String
> [ERROR] reason: inference variable U has incompatible bounds
> [ERROR] equality constraints: java.time.LocalDate
> [ERROR] lower bounds: java.lang.String{code}
>
>
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[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 closed WFLY-13924.
---------------------------------
Resolution: Done
> 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, 2 months
[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, 2 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, 2 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, 2 months