[JBoss JIRA] (WFLY-13887) Add http-connections element to jboss-ejb-client_1_4.xsd schema
by Sudeshna Sur (Jira)
[ https://issues.redhat.com/browse/WFLY-13887?page=com.atlassian.jira.plugi... ]
Sudeshna Sur reassigned WFLY-13887:
-----------------------------------
Assignee: Sudeshna Sur (was: Cheng Fang)
> Add http-connections element to jboss-ejb-client_1_4.xsd schema
> ---------------------------------------------------------------
>
> Key: WFLY-13887
> URL: https://issues.redhat.com/browse/WFLY-13887
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 21.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Sudeshna Sur
> Priority: Major
>
> Need to add the new element to jboss-ejb-client_1_4.xsd schema:
> {code:xml}
> <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.4">
> <client-context default-compression="-1">
> <http-connections>
> <http-connection uri="http://localhost:8180/wildfly-services"/>
> </http-connections>
> </client-context>
> </jboss-ejb-client>
> {code}
> Also need to update jboss-ejb-client.adoc to reflect the new element.
> This element (http-connections) is already implemented as part of WFLY-12190 EJB over HTTP discovery configuration.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
by Sebastian Laskawiec (Jira)
[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ]
Sebastian Laskawiec commented on JGRP-2502:
-------------------------------------------
[~belaban] hmmm tricky one! It depends how do we treat missing namespace. If we treat it as misconfiguration, than what shall we do? Shall we throw an exception?
Alternatively, we can treat the "default" namespace as a sensible default value. It's definitely not a good choice for OpenShift (OpenShift doesn't apply Security Context in the "default" namespace, so users are [discouraged from deploying applications there|https://docs.openshift.com/container-platform/4.5/authentication/ma...]), but it should work fine in vanilla Kubernetes.
Perhaps, the best solution would be to emit a warning that KUBE_PING will use the "default" namespace and that's it. Note, that we would probably need to slightly adjust [this piece of the code|https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src...] (we would need to remove this "if" statement).
> If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2502
> URL: https://issues.redhat.com/browse/JGRP-2502
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.4
> Reporter: Filippe Spolti
> Assignee: Bela Ban
> Priority: Minor
>
> If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below:
>
> {code:java}
> WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]]
> {code}
> IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications.
>
> If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed.
>
> Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace:
>
> {code:java}
> failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]]
> {code}
>
> [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2502:
--------------------------------
[~sebastian.laskawiec] What's the rationale for disabling clustering if namespace is not set? I see many users deploying to {{default}}, and disabling clustering would create a silent src of problems IMO...
> If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2502
> URL: https://issues.redhat.com/browse/JGRP-2502
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.4
> Reporter: Filippe Spolti
> Assignee: Bela Ban
> Priority: Minor
>
> If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below:
>
> {code:java}
> WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]]
> {code}
> IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications.
>
> If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed.
>
> Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace:
>
> {code:java}
> failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]]
> {code}
>
> [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (WFLY-13736) WFLYWELD0041: WeldContainer is not started when redeploying
by Ivo Studensky (Jira)
[ https://issues.redhat.com/browse/WFLY-13736?page=com.atlassian.jira.plugi... ]
Ivo Studensky updated WFLY-13736:
---------------------------------
Summary: WFLYWELD0041: WeldContainer is not started when redeploying (was: [GSS](7.2.z) WFLYWELD0041: WeldContainer is not started when redeploying)
> WFLYWELD0041: WeldContainer is not started when redeploying
> -----------------------------------------------------------
>
> Key: WFLY-13736
> URL: https://issues.redhat.com/browse/WFLY-13736
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Major
>
> Deploy 2 applications where:
> - api is a static module containing EJB Local Interface and transfer objects
> - app2.war has an EJB with a Local interface
> - app1.war has a Servlet that uses @EJB to inject the EJB in app2, it also has a CDI bean with @RequestScoped on it (But the CDI bean is not referenced by anything)
> Start JBoss
> touch app2.war to trigger redeployment and it will fail with the error below.
> It seems redeploying app2 triggers app1 to restart a service based on the logs.
> Note the error only occurs when the CDI bean in app1 has the @RequestScoped annotation
> {code}
> 14:26:38,290 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.6.GA (WildFly Core 6.0.21.Final-redhat-00001) started in 4056ms - Started 537 of 720 services (330 services are lazy, passive or on-demand)
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 73) WFLYUT0022: Unregistered web context: '/app1' from server 'default-server'
> 14:26:43,309 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 7) WFLYUT0022: Unregistered web context: '/app2' from server 'default-server'
> 14:26:43,310 INFO [Servlet] (ServerService Thread Pool -- 73) ***** DESTROY ******
> 14:26:43,353 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0028: Stopped deployment app2.war (runtime-name: app2.war) in 47ms
> 14:26:43,356 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "app2.war" (runtime-name: "app2.war")
> 14:26:43,410 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0003: Processing weld deployment app2.war
> 14:26:43,428 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloEJB' in deployment unit 'deployment "app2.war"' are as follows:
> java:global/app2/HelloEJB!api.HelloLocal
> java:app/app2/HelloEJB!api.HelloLocal
> java:module/HelloEJB!api.HelloLocal
> ejb:/app2/HelloEJB!api.HelloLocal
> java:global/app2/HelloEJB
> java:app/app2/HelloEJB
> java:module/HelloEJB
> 14:26:43,479 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: org.jboss.msc.service.StartException in service jboss.deployment.unit."app1.war".component."org.jboss.weld.module.web.servlet.WeldInitialListener".WeldInstantiator: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1731)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalStateException: WFLYWELD0041: WeldContainer is not started
> at org.jboss.as.weld.WeldBootstrapService.getBeanManager(WeldBootstrapService.java:185)
> at org.jboss.as.weld.injection.WeldComponentService.start(WeldComponentService.java:97)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> ... 6 more
> ...
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2502) If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
by Sebastian Laskawiec (Jira)
[ https://issues.redhat.com/browse/JGRP-2502?page=com.atlassian.jira.plugin... ]
Sebastian Laskawiec commented on JGRP-2502:
-------------------------------------------
[~belaban] [~filippe.spolti] I agree to both:
- This is a valid bug - if a user do not specify a namespace, we should disable clustering.
- And yes, it can be moved to jgroups-kubernetes Github issues.
> If the KUBERNETES_NAMESPACE is not set the default value is the "default" namespace
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2502
> URL: https://issues.redhat.com/browse/JGRP-2502
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 5.0.4
> Reporter: Filippe Spolti
> Assignee: Bela Ban
> Priority: Minor
>
> If no namespace is set it defaults to the "default" ocp namespace which will case the warn as described in the log message below:
>
> {code:java}
> WARN [org.jgroups.protocols.kubernetes.KUBE_PING] (thread-9,ee,hdm78-kieserver-1-nggcf) failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1, headers={Authorization=#MASKED:937#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@69991c01] for cluster [ee], namespace [default], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/namespaces/default/pods]]
> {code}
> IMHO the default namespace should not be used in this case since this namespace should not be used to deploy applications.
>
> If the namespace is not set it means that we do not want to enable the clustering feature, as the namespace is set if the namespace is not set, this condition [1] is not satisfied and the configuration will proceed.
>
> Another problem found in the tests is that, if we do set the KUBERNETES_NAMESPACE with no value, it will detect that the env has an value and will try to use a blank namespace:
>
> {code:java}
> failed getting JSON response from Kubernetes Client[masterUrl=https://172.30.0.1:443/api/v1 , headers={Authorization=#MASKED:874#}, connectTimeout=5000, readTimeout=30000, operationAttempts=3, operationSleep=1000, streamProvider=org.jgroups.protocols.kubernetes.stream.TokenStreamProvider@17978314] for cluster [ee], namespace [], labels [null]; encountered [java.lang.Exception: 3 attempt(s) with a 1000ms sleep to execute [OpenStream] failed. Last failure was [java.io.IOException: Server returned HTTP response code: 403 for URL: https://172.30.0.1:443/api/v1/pods ]]
> {code}
>
> [1] - https://github.com/jgroups-extras/jgroups-kubernetes/blob/master/src/main/java/org/jgroups/protocols/kubernetes/KUBE_PING.java#L145
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (JGRP-2503) Extend DataInput & DataOutput to avoid copy of byte[]
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2503?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2503 at 9/23/20 7:00 AM:
---------------------------------------------------------
Related to the byte[] copy in [1]
[1] [https://github.com/belaban/JGroups/blob/master/src/org/jgroups/NioMessage...]
was (Author: belaban):
Hmm, perhaps directly modify {{Streamable}}, then we could get rid of the byte[] copy in [1]
[1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/NioMessage...
> Extend DataInput & DataOutput to avoid copy of byte[]
> -----------------------------------------------------
>
> Key: JGRP-2503
> URL: https://issues.redhat.com/browse/JGRP-2503
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 5.0.4
> Reporter: Jingqi Xu
> Assignee: Bela Ban
> Priority: Optional
>
> "DataInput's void readFully(byte b[])" will cause an extra copy when reading bytes from DataInput. Sometimes business logic needs to read bytes from DataInput first, then process them conditionally(or will not process at all) , is it possible to support ByteBuffer api like:
> public interface XDataInput extends DataInput {
> ByteBuffer readBuffer(int n);
> }
> public interface XDataOutput extends DataOutput {
> void writeBuffer(ByteBuffer value);
> }
> ByteArrayDataInputStream.java
> @Override
> public ByteBuffer readBuffer(int n) {
> ByteBuffer r = wrap(this.buf, this.pos, n); this.pos += n; return r;
> }
> public interface Streamable {
> void writeTo(XDataOutput out) throws IOException;
> void readFrom(XDataInput in) throws IOException, ClassNotFoundException;
> }
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months