[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
jaikiran pai updated WFLY-9869:
-------------------------------
Affects Version/s: 12.0.0.Beta1
> Pure HTTP EJB invocation not working
> ------------------------------------
>
> Key: WFLY-9869
> URL: https://issues.jboss.org/browse/WFLY-9869
> Project: WildFly
> Issue Type: Quality Risk
> Components: EJB
> Affects Versions: 11.0.0.Final, 12.0.0.Beta1
> Environment: Debian 9 - 64-bit
> Reporter: Andre Izu
> Assignee: Stuart Douglas
> Labels: ejb, pure_http
> Attachments: ejb-http-client.zip
>
>
> I have been trying to make the "pure" http EJB invocation from a remote server instance, without success.
> The client module was built inside a war file, while the server artifact was build in an ear file.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080" or "http://localhost:8080/wildfly-services", the remote invocation works fine via main() method.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080", the remote invocation works fine via http://localhost:8080/web/index.jsp (client application calling server application)
> Now when I set the Context.PROVIDER_URL to "http://localhost:8080/wildfly-services", the remote invocation via http://localhost:8080/web/index.jsp (client application calling server application) returns:
> {panel:title=Client application calling server application}
> 2018-01-05 15:30:07,346 INFO [stdout] (default task-44) jndiName: ejb:wejb/wejb/CalculatorEJB!br.com.server.Calculator
> 2018-01-05 15:30:07,351 INFO [stdout] (default task-44) Proxy for remote EJB StatelessEJBLocator for "wejb/wejb/CalculatorEJB", view is interface br.com.server.Calculator, affinity is None
> 2018-01-05 15:30:07,352 ERROR [io.undertow.request] (default task-44) UT005023: Exception handling request to /web/: org.apache.jasper.JasperException: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$852/801580157.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.jboss.ejb.client.EJBReceiverInvocationContext$ResultProducer$Failed.getResult(EJBReceiverInvocationContext.java:151)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:118)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:907)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:165)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy61.calculateInterest(Unknown Source)
> at br.com.client.RemoteEJBClient.main(RemoteEJBClient.java:20)
> at br.com.client.RemoteEJBClient.func(RemoteEJBClient.java:14)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:99)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 47 more
> Suppressed: javax.ejb.NoSuchEJBException: EJBCLIENT000024: No EJB receiver available for handling destination "http://localhost:8080/wildfly-services"
> at org.jboss.ejb.client.EJBClientContext.resolveReceiver(EJBClientContext.java:571)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:438)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:90)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:66)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:165)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.EJBClientInvocationContext$$Lambda$915/72354668.accept(Unknown Source)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:302)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:161)
> ... 55 more
> {panel}
> This behaviour is reproduceable with the attached project. One detail not mentioned in the jboss forum is that I started wildfly 11 with standalone-full.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
jaikiran pai commented on WFLY-9869:
------------------------------------
FWIW - A quick look suggests that the HTTP {{EJBTransportProvider}} isn't (auto) registered for deployments, just causing EJB invocations from servers (which act as a client in the invocation), failing for the {{http}} scheme.
> Pure HTTP EJB invocation not working
> ------------------------------------
>
> Key: WFLY-9869
> URL: https://issues.jboss.org/browse/WFLY-9869
> Project: WildFly
> Issue Type: Quality Risk
> Components: EJB
> Affects Versions: 11.0.0.Final
> Environment: Debian 9 - 64-bit
> Reporter: Andre Izu
> Assignee: Stuart Douglas
> Labels: ejb, pure_http
> Attachments: ejb-http-client.zip
>
>
> I have been trying to make the "pure" http EJB invocation from a remote server instance, without success.
> The client module was built inside a war file, while the server artifact was build in an ear file.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080" or "http://localhost:8080/wildfly-services", the remote invocation works fine via main() method.
> When I set the Context.PROVIDER_URL to "remote+http://127.0.0.1:8080", the remote invocation works fine via http://localhost:8080/web/index.jsp (client application calling server application)
> Now when I set the Context.PROVIDER_URL to "http://localhost:8080/wildfly-services", the remote invocation via http://localhost:8080/web/index.jsp (client application calling server application) returns:
> {panel:title=Client application calling server application}
> 2018-01-05 15:30:07,346 INFO [stdout] (default task-44) jndiName: ejb:wejb/wejb/CalculatorEJB!br.com.server.Calculator
> 2018-01-05 15:30:07,351 INFO [stdout] (default task-44) Proxy for remote EJB StatelessEJBLocator for "wejb/wejb/CalculatorEJB", view is interface br.com.server.Calculator, affinity is None
> 2018-01-05 15:30:07,352 ERROR [io.undertow.request] (default task-44) UT005023: Exception handling request to /web/: org.apache.jasper.JasperException: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:473)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.jsp.JspFileHandler.handleRequest(JspFileHandler.java:32)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$852/801580157.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$853/1002843216.call(Unknown Source)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available
> at org.jboss.ejb.client.EJBReceiverInvocationContext$ResultProducer$Failed.getResult(EJBReceiverInvocationContext.java:151)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:567)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocationResult(RemotingEJBClientInterceptor.java:56)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocationResult(TransactionPostDiscoveryInterceptor.java:133)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocationResult(DiscoveryEJBClientInterceptor.java:118)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocationResult(NamingEJBClientInterceptor.java:78)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:172)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:569)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:503)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:907)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:165)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:100)
> at com.sun.proxy.$Proxy61.calculateInterest(Unknown Source)
> at br.com.client.RemoteEJBClient.main(RemoteEJBClient.java:20)
> at br.com.client.RemoteEJBClient.func(RemoteEJBClient.java:14)
> at org.apache.jsp.index_jsp._jspService(index_jsp.java:99)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:433)
> ... 47 more
> Suppressed: javax.ejb.NoSuchEJBException: EJBCLIENT000024: No EJB receiver available for handling destination "http://localhost:8080/wildfly-services"
> at org.jboss.ejb.client.EJBClientContext.resolveReceiver(EJBClientContext.java:571)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:438)
> at org.jboss.ejb.protocol.remote.RemotingEJBClientInterceptor.handleInvocation(RemotingEJBClientInterceptor.java:51)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionPostDiscoveryInterceptor.handleInvocation(TransactionPostDiscoveryInterceptor.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.DiscoveryEJBClientInterceptor.handleInvocation(DiscoveryEJBClientInterceptor.java:90)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.NamingEJBClientInterceptor.handleInvocation(NamingEJBClientInterceptor.java:66)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:165)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:466)
> at org.jboss.ejb.client.EJBClientInvocationContext$$Lambda$915/72354668.accept(Unknown Source)
> at org.wildfly.common.context.Contextual.runExConsumer(Contextual.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequestInitial(EJBClientInvocationContext.java:302)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:161)
> ... 55 more
> {panel}
> This behaviour is reproduceable with the attached project. One detail not mentioned in the jboss forum is that I started wildfly 11 with standalone-full.xml
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2347) ProtobufOutputMarshaller.orderFacts causes a "Comparison method violates its general contract" error
by Martin Weiler (JIRA)
Martin Weiler created DROOLS-2347:
-------------------------------------
Summary: ProtobufOutputMarshaller.orderFacts causes a "Comparison method violates its general contract" error
Key: DROOLS-2347
URL: https://issues.jboss.org/browse/DROOLS-2347
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.6.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
When marshalling kieSession in production (long running kieSession with a lot of fact insertion), we encountered the following error :
{noformat}
java.lang.IllegalArgumentException: Comparison method violates its general contract!
at java.util.TimSort.mergeLo(TimSort.java:777)
at java.util.TimSort.mergeAt(TimSort.java:514)
at java.util.TimSort.mergeCollapse(TimSort.java:439)
at java.util.TimSort.sort(TimSort.java:245)
at java.util.Arrays.sort(Arrays.java:1438)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.orderFacts(ProtobufOutputMarshaller.java:776)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeFactHandles(ProtobufOutputMarshaller.java:707)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:176)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:120)
at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:164)
at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148)
{noformat}
Indeed, the orderFacts method in ProtobufoutputMarshaller uses a HandleSorter as comparator, which returns the result of o1.getId() - o2.getId() where o1 and o2 are InternalFactHandle.
Since the id of InternalFactHandle is an int, this comparator can cause "Comparison method violates its general contract!" IllegalArgumentException because Integer.MAX_INT + 1 < 0.
The comparator should return the result of Integer.compare(o1.getId(), o2.getId())
The root cause is that InternalFactHandle.getId() is an int and should be a long for long running kieSession.
This id is generated by the FactHandleFactory (in AbstractFactHandleFactory) and is an AtomicInteger incremented at each fact creation.
With long running kieSession a lot of fact handles can be created (inserted in memory or with "from") so this id can overflow Integer.MAX_INT and become negative, causing this issue when ordering.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9854) jgroups-cluster cannot use name which is already used by jgroups/stacks
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-9854?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-9854:
----------------------------------
{quote}
I see Paul's point that the configuration is quite specific and unlikely. However the WildFly Continuous Delivery document \[1\] is strict about backward compatibility. Based on the document it is valid issue.
[~kabirkhan] [~msvehla] Who should make the final decision in these cases? When is it acceptable to relax the backward compatibility rules?
\[1\] https://docs.google.com/document/d/1dH-Mc4p_ZogZVWhc6dDdW1tfPIp45MBVeSxwS...
[~jason.greene] wdyt ^^?
> jgroups-cluster cannot use name which is already used by jgroups/stacks
> -----------------------------------------------------------------------
>
> Key: WFLY-9854
> URL: https://issues.jboss.org/browse/WFLY-9854
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Affects Versions: 12.0.0.Beta1
> Reporter: Erich Duda
> Assignee: Paul Ferraro
> Priority: Blocker
>
> The configuration \[1\] results to an error \[2\]. This is backward compatibility issue since the configuration works with previous releases of Wildfly.
> \[1\]
> {code:xml}
> <broadcast-group name="bg-group1" jgroups-stack="udp" jgroups-cluster="udp" broadcast-period="2000" connectors="connector"/>
> {code}
> \[2\]
> {code}
> 10:52:29,982 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 15) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "udp")
> ]) - failure description: "WFLYCTL0436: Cannot register capability 'org.wildfly.clustering.jgroups.channel-factory.udp' at location '[
> (\"subsystem\" => \"jgroups\"),
> (\"channel\" => \"udp\")
> ]' as it is already registered in context 'global' at location(s) '[[
> (\"subsystem\" => \"jgroups\"),
> (\"stack\" => \"udp\")
> ]]'"
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2346) ProtobufOutputMarshaller.orderFacts causes a "Comparison method violates its general contract" error
by Martin Weiler (JIRA)
Martin Weiler created DROOLS-2346:
-------------------------------------
Summary: ProtobufOutputMarshaller.orderFacts causes a "Comparison method violates its general contract" error
Key: DROOLS-2346
URL: https://issues.jboss.org/browse/DROOLS-2346
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.6.0.Final
Reporter: Martin Weiler
Assignee: Mario Fusco
When marshalling kieSession in production (long running kieSession with a lot of fact insertion), we encountered the following error :
{noformat}
java.lang.IllegalArgumentException: Comparison method violates its general contract!
at java.util.TimSort.mergeLo(TimSort.java:777)
at java.util.TimSort.mergeAt(TimSort.java:514)
at java.util.TimSort.mergeCollapse(TimSort.java:439)
at java.util.TimSort.sort(TimSort.java:245)
at java.util.Arrays.sort(Arrays.java:1438)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.orderFacts(ProtobufOutputMarshaller.java:776)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeFactHandles(ProtobufOutputMarshaller.java:707)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:176)
at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:120)
at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:164)
at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148)
{noformat}
Indeed, the orderFacts method in ProtobufoutputMarshaller uses a HandleSorter as comparator, which returns the result of o1.getId() - o2.getId() where o1 and o2 are InternalFactHandle.
Since the id of InternalFactHandle is an int, this comparator can cause "Comparison method violates its general contract!" IllegalArgumentException because Integer.MAX_INT + 1 < 0.
The comparator should return the result of Integer.compare(o1.getId(), o2.getId())
The root cause is that InternalFactHandle.getId() is an int and should be a long for long running kieSession.
This id is generated by the FactHandleFactory (in AbstractFactHandleFactory) and is an AtomicInteger incremented at each fact creation.
With long running kieSession a lot of fact handles can be created (inserted in memory or with "from") so this id can overflow Integer.MAX_INT and become negative, causing this issue when ordering.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2345) It is not possible to define parent and child service in the same kie.conf
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2345?page=com.atlassian.jira.plugi... ]
Tibor Zimányi commented on DROOLS-2345:
---------------------------------------
I propose a fix, where multiple services could be defined on the same line in kie.conf. See PR: https://github.com/kiegroup/droolsjbpm-knowledge/pull/296
> It is not possible to define parent and child service in the same kie.conf
> --------------------------------------------------------------------------
>
> Key: DROOLS-2345
> URL: https://issues.jboss.org/browse/DROOLS-2345
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.6.0.Final
> Reporter: Tibor Zimányi
> Assignee: Tibor Zimányi
> Priority: Minor
> Fix For: 7.7.0.Final
>
>
> When using just one kie.conf file for all services, it is not possible to define parent and child service in the same file. This is mainly the case when having an uberjar with all kie dependencies bundled in. In such case such kie.conf file is needed for service registry to work.
> E.g. a user wants to add DMNAssemblerService to kie.conf,
> org.kie.api.internal.assembler.KieAssemblers = +org.kie.dmn.core.assembler.DMNAssemblerService
> In such case service discovery fails with an exception
> java.lang.RuntimeException: Child services [org.kie.api.internal.assembler.KieAssemblers] have no parent
> I have a proposed fix ready. Will create a PR with it and a reproducer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (DROOLS-2345) It is not possible to define parent and child service in the same kie.conf
by Tibor Zimányi (JIRA)
Tibor Zimányi created DROOLS-2345:
-------------------------------------
Summary: It is not possible to define parent and child service in the same kie.conf
Key: DROOLS-2345
URL: https://issues.jboss.org/browse/DROOLS-2345
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.6.0.Final
Reporter: Tibor Zimányi
Assignee: Tibor Zimányi
Priority: Minor
Fix For: 7.7.0.Final
When using just one kie.conf file for all services, it is not possible to define parent and child service in the same file. This is mainly the case when having an uberjar with all kie dependencies bundled in. In such case such kie.conf file is needed for service registry to work.
E.g. a user wants to add DMNAssemblerService to kie.conf,
org.kie.api.internal.assembler.KieAssemblers = +org.kie.dmn.core.assembler.DMNAssemblerService
In such case service discovery fails with an exception
java.lang.RuntimeException: Child services [org.kie.api.internal.assembler.KieAssemblers] have no parent
I have a proposed fix ready. Will create a PR with it and a reproducer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9888) Server log messages does not reflect the use of "distinct" naming for EJB's
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-9888:
--------------------------------------
Summary: Server log messages does not reflect the use of "distinct" naming for EJB's
Key: WFLY-9888
URL: https://issues.jboss.org/browse/WFLY-9888
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: Wolf-Dieter Fink
Priority: Minor
If an application (jboss-ejb3.xml) or server configuration is marked with the distinct flag
<jboss:ejb-jar .... version="3.1" impl-version="2.0">
<distinct-name>WOLF</distinct-name>
</jboss:ejb-jar>
The client need to use the the correct lookup with distinct name
"ejb:MyEAR/MyEjbJar/WOLF/MyBean!MyInterface
to get the bean proxy.
Unfortunately there is no hint whether an application is marked with this distinct flag.
The server log still show the same output as without like this:
INFO WFLYEJB0473: JNDI bindings for session bean named 'SimpleBean' in deployment unit 'subdeployment "ejb.jar" of deployment "EAP71-PLAYGROUND-server.ear"' are as follows:
java:global/EAP71-PLAYGROUND-server/ejb/SimpleBean!org.jboss.wfink.eap71.playground.Simple
It would be good if the log message show the correct JNDI name or a hint that the EJB has a distinct name applied.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (WFLY-9889) Server log messages does not reflect the use of "distinct" naming for EJB's
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-9889:
--------------------------------------
Summary: Server log messages does not reflect the use of "distinct" naming for EJB's
Key: WFLY-9889
URL: https://issues.jboss.org/browse/WFLY-9889
Project: WildFly
Issue Type: Enhancement
Components: EJB
Reporter: Wolf-Dieter Fink
Priority: Minor
If an application (jboss-ejb3.xml) or server configuration is marked with the distinct flag
<jboss:ejb-jar .... version="3.1" impl-version="2.0">
<distinct-name>WOLF</distinct-name>
</jboss:ejb-jar>
The client need to use the the correct lookup with distinct name
"ejb:MyEAR/MyEjbJar/WOLF/MyBean!MyInterface
to get the bean proxy.
Unfortunately there is no hint whether an application is marked with this distinct flag.
The server log still show the same output as without like this:
INFO WFLYEJB0473: JNDI bindings for session bean named 'SimpleBean' in deployment unit 'subdeployment "ejb.jar" of deployment "EAP71-PLAYGROUND-server.ear"' are as follows:
java:global/EAP71-PLAYGROUND-server/ejb/SimpleBean!org.jboss.wfink.eap71.playground.Simple
It would be good if the log message show the correct JNDI name or a hint that the EJB has a distinct name applied.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months