[JBoss JIRA] (WFLY-12630) Document usage of EJB and JMS Client BOM in Quickstarts
by Eduardo Martins (Jira)
Eduardo Martins created WFLY-12630:
--------------------------------------
Summary: Document usage of EJB and JMS Client BOM in Quickstarts
Key: WFLY-12630
URL: https://issues.jboss.org/browse/WFLY-12630
Project: WildFly
Issue Type: Enhancement
Components: Quickstarts
Reporter: Eduardo Martins
Assignee: Eduardo Martins
Fix For: 18.0.0.Final
All JAXWS Quickstarts should explain usage of the JAXWS Client BOM as the proper way to manage/use the dependencies in server, assuring compatibility with it. Traditionally this kind of guidance is done along the reference to the BOM is pom.xml
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFWIP-189) Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin.... ]
Petr Kremensky commented on WFWIP-189:
--------------------------------------
Thanks for looking into this, even community seem to be split regarding the "versioning" of the config maps and secrets (https://github.com/kubernetes/kubernetes/issues/22368), I agree it's not clever to go against the whole world here, let us be consistent with Kubernetes, at least for now. If some enhancements are requested by customers on this, EAP7 jira should be created and properly prioritized by PM.
I'll close this one, add the proposed way of using the config maps and secrets into our testsuite and create a JBEAP documentation jira to make sure this will be part of our documentation.
> Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-189
> URL: https://issues.jboss.org/browse/WFWIP-189
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: operator
>
> User is able to share environment variables in a ConfigMap or Secret and pass it to Operator via [WildFlyServerSpec#envFrom|https://github.com/wildfly/wildfly-operator/blo...] field. Problem is, that Operator is not aware of changes in Secret/ConfigMap (only reference change is recognized - add or remove ConfigMap/Secret reference). This could lead to inconsistency of environment between pods in a single project (moreover this could lead also to inconsistency between projects in case that ConfigMap/Secret is shared by them).
> The reaction on ConfigMap/Secret content should be doable, see https://blog.questionable.services/article/kubernetes-deployments-configm...
> *reproduce*
> * create a config map with ("foo1", "bar1") entry
> * create an operator (size = 1) with a reference to the config map
> * update the config map - add ("foo2", "bar2") entry
> * resize the operator
> *actual*
> {code}
> $ oc get pods
> NAME READY STATUS RESTARTS AGE
> eap-cd-0 1/1 Running 0 112s
> eap-cd-1 1/1 Running 0 94s
> wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *expected*
> {code}
> $ oc get pods
> NAME READY STATUS RESTARTS AGE
> eap-cd-0 1/1 Running 0 112s
> eap-cd-1 1/1 Running 0 94s
> wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *Environment:*
> *operator version:* [467407a|https://github.com/wildfly/wildfly-operator/commit/467407a6c21102...]
> *openshift version:*
> {noformat}
> OpenShift version: 4.1.11
> Kubernetes Master Version: v1.13.4+df9cebc
> {noformat}
> Out of curiosity, is there is way to rollout the pods manually as {{oc rollout}} was designed for DeploymentConfigs and cannot be used here?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFWIP-189) Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin.... ]
Petr Kremensky closed WFWIP-189.
--------------------------------
Resolution: Explained
> Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-189
> URL: https://issues.jboss.org/browse/WFWIP-189
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: operator
>
> User is able to share environment variables in a ConfigMap or Secret and pass it to Operator via [WildFlyServerSpec#envFrom|https://github.com/wildfly/wildfly-operator/blo...] field. Problem is, that Operator is not aware of changes in Secret/ConfigMap (only reference change is recognized - add or remove ConfigMap/Secret reference). This could lead to inconsistency of environment between pods in a single project (moreover this could lead also to inconsistency between projects in case that ConfigMap/Secret is shared by them).
> The reaction on ConfigMap/Secret content should be doable, see https://blog.questionable.services/article/kubernetes-deployments-configm...
> *reproduce*
> * create a config map with ("foo1", "bar1") entry
> * create an operator (size = 1) with a reference to the config map
> * update the config map - add ("foo2", "bar2") entry
> * resize the operator
> *actual*
> {code}
> $ oc get pods
> NAME READY STATUS RESTARTS AGE
> eap-cd-0 1/1 Running 0 112s
> eap-cd-1 1/1 Running 0 94s
> wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *expected*
> {code}
> $ oc get pods
> NAME READY STATUS RESTARTS AGE
> eap-cd-0 1/1 Running 0 112s
> eap-cd-1 1/1 Running 0 94s
> wildfly-operator-55b544c4bb-wts8l 1/1 Running 0 2m1s
> $ oc rsh pod/eap-cd-0
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> $ oc rsh pod/eap-cd-1
> sh-4.4$ env | grep foo
> foo1=bar1
> foo2=bar2
> {code}
> *Environment:*
> *operator version:* [467407a|https://github.com/wildfly/wildfly-operator/commit/467407a6c21102...]
> *openshift version:*
> {noformat}
> OpenShift version: 4.1.11
> Kubernetes Master Version: v1.13.4+df9cebc
> {noformat}
> Out of curiosity, is there is way to rollout the pods manually as {{oc rollout}} was designed for DeploymentConfigs and cannot be used here?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month
[JBoss JIRA] (WFLY-9869) Pure HTTP EJB invocation not working
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-9869?page=com.atlassian.jira.plugin.... ]
Brian Stansberry closed WFLY-9869.
----------------------------------
> 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
> Priority: Major
> Labels: ejb, pure_http
> Fix For: 12.0.0.CR1, 12.0.0.Final
>
> 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.13.8#713008)
6 years, 1 month
[JBoss JIRA] (JGRP-2387) Message from a non-member causes FD_ALL to continually suspect it
by Dennis Reed (Jira)
[ https://issues.jboss.org/browse/JGRP-2387?page=com.atlassian.jira.plugin.... ]
Dennis Reed updated JGRP-2387:
------------------------------
Attachment: Test.java
> Message from a non-member causes FD_ALL to continually suspect it
> -----------------------------------------------------------------
>
> Key: JGRP-2387
> URL: https://issues.jboss.org/browse/JGRP-2387
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.1
> Reporter: Dennis Reed
> Assignee: Bela Ban
> Priority: Major
> Attachments: Test.java
>
>
> If a FD_SOCK control message from a non-member is seen by FD_SOCK, it will start continually suspecting that node. If msg_counts_as_heartbeat=true then any message from a non-member triggers the issue. The issue is cleared on the next view change.
> This does not cause any functional issues in the cluster, but can cause repeated WARN logs in some cases.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 1 month