[JBoss JIRA] (WFLY-12614) Duplicated ConstraintViolation message
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-12614?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFLY-12614:
-------------------------------------
[~brian.stansberry], I did the validation integration years ago, which has some peculiar twists and turns, mainly because of CDI interfering with the order of things. I've tracked down edge cases over the years, so much so that I'm reminded of Captain Ahab: "He tasks me; he heaps me; I see in him outrageous strength, with an inscrutable malice sinewing it." ;-)
I'll take a look.
> Duplicated ConstraintViolation message
> --------------------------------------
>
> Key: WFLY-12614
> URL: https://issues.jboss.org/browse/WFLY-12614
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 17.0.1.Final, 18.0.0.Beta1
> Reporter: Robin Schimpf
> Assignee: Alessio Soldano
> Priority: Major
> Attachments: wildfly-bug.zip
>
>
> We currently are upgrading our application from Wildfly 13 to Wildfly 17.0.1 and are receiving duplicated constraint violations in the response of an invalid request.
> Interestingly Wildfly 13 also seems to be not behaving correctly on the third request but in another way. There is the violation exception returned in the response instead of the duplicated value Wildfly 17 is returning now.
> I also tested this on the currently available Wildfly 18 Beta 1 and the issue is also reproducible.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-189) Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-189:
-----------------------------------
This problem is not specific to the operator and is something inherent to Kubernetes.
There are various approaches to mitigate this issue and they all seem ad hoc...
The solution mentioned in https://blog.questionable.services/article/kubernetes-deployments-configm... is not sufficient. It requires to watch for any config map / secrets that the application references and compute their checksum and put that info in the WildFlyServer resources. This goes beyond what the operator should deal with (and still leaves some windows that would result in inconsistencies between pods).
As far as I can tell the best way to mitigate that issue is to "version" the names of the config maps referenced by the operator.
Eg.
{code}
spec:
envFrom:
- configMapRef:
name: my-config-1
{code}
If a change must be made to the config map, it can be copied to another config map named config-2.
Then the WildFlyServer Spec can be updated with that info:
{code}
spec:
envFrom:
- configMapRef:
name: my-config-2
{code}
I don't think the operator should change the semantic and behaviour of the existing Kubernetes resources. it should comply with it and works in a way that is consistent with Kubernetes. It is known that updating a config map will not trigger a rollout of a deployment (even more so any change in a statefulset).
> 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, 7 months
[JBoss JIRA] (WFWIP-189) Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-189?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFWIP-189:
------------------------------
Summary: Operator is not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies (was: Operatoris not aware of Secret/ConfigMap updates (WildFlyServerSpec#envFrom) - this could lead to inconsistencies)
> 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, 7 months
[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFWIP-218:
--------------------------------------
In this scenario, the transaction is recovered (committed) correctly. The server waits for the client before scale-down as well. The problem is that during the recovery the logs on the server-side are not being cleared (because XAResourceRegistry is not serialized; null in code below).
{code}
try {
if (commitToEnlistment()) lookup(xid).commit(onePhase);
} catch (XAException | RuntimeException exception) {
if (resourceRegistry != null)
resourceRegistry.resourceInDoubt(this);
throw exception;
}
if (resourceRegistry != null)
resourceRegistry.removeResource(this);
}
{code}
This is a bug but it does not cause incorrect transaction recovery. As a result, I'm downgrading it from the blocker status.
> server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
> --------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-218
> URL: https://issues.jboss.org/browse/WFWIP-218
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Blocker
>
> this follows up on WFWIP-206
> While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful
> Scenario:
> *ejb client* (app tx-client, pod tx-client-0):
> * EJB business method
> ** lookup remote EJB
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ** call remote EJB
> *ejb server* (app tx-server, pod tx-server-0):
> * EJB business method
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> *testTxStatelessServerSecondCommitThrowRmFail*
> ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}}
> Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
by Tomasz Adamski (Jira)
[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski updated WFWIP-218:
---------------------------------
Priority: Major (was: Blocker)
> server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited
> --------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-218
> URL: https://issues.jboss.org/browse/WFWIP-218
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Major
>
> this follows up on WFWIP-206
> While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful
> Scenario:
> *ejb client* (app tx-client, pod tx-client-0):
> * EJB business method
> ** lookup remote EJB
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> ** call remote EJB
> *ejb server* (app tx-server, pod tx-server-0):
> * EJB business method
> ** enlist XA resource 1 to transaction
> ** enlist XA resource 2 to transaction
> *testTxStatelessServerSecondCommitThrowRmFail*
> ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}}
> Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-226) ASYM_ENCRYPT configuration from S2I build/runtime configuration is wrong
by Jean Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFWIP-226?page=com.atlassian.jira.plugin.... ]
Jean Francois Denise commented on WFWIP-226:
--------------------------------------------
[~mjurc], it is the subsystem tha tname the protocol tha tway. I did: /subsystem=jgroups/stack=tcp/protocol=ASYM_ENCRYPT:add(add-index=0)
with WildFly 18, and the name is the same as the one you are observing.
> ASYM_ENCRYPT configuration from S2I build/runtime configuration is wrong
> ------------------------------------------------------------------------
>
> Key: WFWIP-226
> URL: https://issues.jboss.org/browse/WFWIP-226
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: KUBERNETES_LABEL=deploymentconfig=jgroups
> JGROUPS_ENCRYPT_PROTOCOL=ASYM_ENCRYPT
> JGROUPS_CLUSTER_PASSWORD=foobar123
> KUBERNETES_NAMESPACE=mjurc-namespace
> JGROUPS_PING_PROTOCOL=kubernetes.KUBE_PING
> Reporter: Michal Jurc
> Assignee: Yeray Borges
> Priority: Blocker
>
> Deployment of application fails on runtime configured by S2I mechanisms with new Galleon image with the following message:
> {code:bash}13:10:50,722 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 81) MSC000001: Failed to start service org.wildfly.clustering.jgroups.channel.ee: org.jboss.msc.service.StartException in service org.wildfly.clustering.jgroups.channel.ee: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> at org.wildfly.clustering.service@7.3.0.CD18-redhat-SNAPSHOT//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70)
> at org.wildfly.clustering.service@7.3.0.CD18-redhat-SNAPSHOT//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$start$0(AsyncServiceConfigurator.java:117)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:116)
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:58)
> at org.wildfly.clustering.service@7.3.0.CD18-redhat-SNAPSHOT//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67)
> ... 7 more
> Caused by: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> at java.base/java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:236)
> at org.jgroups@4.1.4.Final//org.jgroups.protocols.ASYM_ENCRYPT.initKeyPair(ASYM_ENCRYPT.java:507)
> at org.jgroups@4.1.4.Final//org.jgroups.protocols.ASYM_ENCRYPT.init(ASYM_ENCRYPT.java:105)
> at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:861)
> at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:849)
> at org.jgroups(a)4.1.4.Final//org.jgroups.JChannel.<init>(JChannel.java:155)
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:116)
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:96)
> ... 9 more
> 13:10:51,021 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 81) WFLYMSGAMQ0002: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> 13:10:51,043 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 83) WFLYMSGAMQ0002: Bound messaging object to jndi name java:/ConnectionFactory
> 13:10:51,108 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0007: Registered connection factory java:/JmsXA
> 13:10:51,269 INFO [org.apache.activemq.artemis.ra] (MSC service thread 1-1) AMQ151007: Resource adaptor started
> 13:10:51,269 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-1) IJ020002: Deployed: file://RaActivatoractivemq-ra
> 13:10:51,271 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0002: Bound JCA ConnectionFactory [java:/JmsXA]
> 13:10:51,271 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0118: Binding connection factory named java:/JmsXA to alias java:jboss/DefaultJMSConnectionFactory
> 13:10:51,440 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.clustering.jgroups.channel.ee" => "java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> Caused by: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> Caused by: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available"}}
> 13:10:51,455 INFO [org.jboss.as.server] (ServerService Thread Pool -- 45) WFLYSRV0010: Deployed "ROOT.war" (runtime-name : "ROOT.war")
> 13:10:51,458 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service org.wildfly.clustering.jgroups.channel.ee: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> WFLYCTL0448: 38 additional services are down due to their dependencies being missing or failed
> 13:10:51,569 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:10:51,579 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
> 13:10:51,579 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0054: Admin console is not enabled
> 13:10:51,579 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP CD 7.3.0.CD18 (WildFly Core 10.0.1.Final-redhat-SNAPSHOT) started (with errors) in 9553ms - Started 476 of 835 services (35 services failed or missing dependencies, 541 services are lazy, passive or on-demand)
> ERROR *** JBossAS wrapper process (1) received TERM signal ***
> {code}
> The same deployment with same deployment config will not fail with previous images.
> There's an actual difference in outputted JGroups configuration:
> {code:title=7.3.0.Beta} <protocol type="ASYM_ENCRYPT">
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> <property name="change_key_on_leave">true</property>
> </protocol>
> {code}
> {code:title=New image} <protocol type="org.jgroups.protocols.ASYM_ENCRYPT">
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">true</property>
> </protocol>{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFLY-12628) Downgrade MicroProfile Health to 2.0.1
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12628?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFLY-12628:
-------------------------------
Description:
MP Health was upgraded to 2.1 in WFLY-12555 at the same time that smallrye-health was upgrade to 2.0.0 in WFLY-12554
That was a mistake as smallrye-health is depending on MP Health 2.0.1.
There is no harm on staying on MP Health 2.1 as the API changes are internal to the API and do not require any implementation from the provider:
https://github.com/eclipse/microprofile-health/compare/2.0.1...2.1
However, if we decide to keep WildFly 18 under the same MP Umbrella release (3.0) at the moment, it might be better to downgrade to 2.0.1
was:
MP Health was upgraded to 2.1 in WFLY-12555 at the same time that smallrye-health was upgrade to 2.0.0 in WFLY-12554
That was a mistake as smallrye-health is depending on MP Health 2.0.1.
There is no harm on staying on MP Health 2.1 as the API changes are internal to the API and do not require any implementation from the provider.
However, if we decide to keep WildFly 18 under the same MP Umbrella release (3.0) at the moment, it might be better to downgrade to 2.0.1
> Downgrade MicroProfile Health to 2.0.1
> --------------------------------------
>
> Key: WFLY-12628
> URL: https://issues.jboss.org/browse/WFLY-12628
> Project: WildFly
> Issue Type: Component Upgrade
> Components: MP Health
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Major
>
> MP Health was upgraded to 2.1 in WFLY-12555 at the same time that smallrye-health was upgrade to 2.0.0 in WFLY-12554
> That was a mistake as smallrye-health is depending on MP Health 2.0.1.
> There is no harm on staying on MP Health 2.1 as the API changes are internal to the API and do not require any implementation from the provider:
> https://github.com/eclipse/microprofile-health/compare/2.0.1...2.1
> However, if we decide to keep WildFly 18 under the same MP Umbrella release (3.0) at the moment, it might be better to downgrade to 2.0.1
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months
[JBoss JIRA] (WFWIP-226) ASYM_ENCRYPT configuration from S2I build/runtime configuration is wrong
by Jan Blizňák (Jira)
[ https://issues.jboss.org/browse/WFWIP-226?page=com.atlassian.jira.plugin.... ]
Jan Blizňák commented on WFWIP-226:
-----------------------------------
The problem is probably here:
https://github.com/wildfly/wildfly-cekit-modules/blob/master/jboss/contai...
Also would make sense to fix tests to expect correct output:
https://github.com/wildfly/wildfly-cekit-modules/blob/master/jboss/contai...
https://github.com/wildfly/wildfly-cekit-modules/blob/master/jboss/contai...
> ASYM_ENCRYPT configuration from S2I build/runtime configuration is wrong
> ------------------------------------------------------------------------
>
> Key: WFWIP-226
> URL: https://issues.jboss.org/browse/WFWIP-226
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: KUBERNETES_LABEL=deploymentconfig=jgroups
> JGROUPS_ENCRYPT_PROTOCOL=ASYM_ENCRYPT
> JGROUPS_CLUSTER_PASSWORD=foobar123
> KUBERNETES_NAMESPACE=mjurc-namespace
> JGROUPS_PING_PROTOCOL=kubernetes.KUBE_PING
> Reporter: Michal Jurc
> Assignee: Yeray Borges
> Priority: Blocker
>
> Deployment of application fails on runtime configured by S2I mechanisms with new Galleon image with the following message:
> {code:bash}13:10:50,722 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 81) MSC000001: Failed to start service org.wildfly.clustering.jgroups.channel.ee: org.jboss.msc.service.StartException in service org.wildfly.clustering.jgroups.channel.ee: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> at org.wildfly.clustering.service@7.3.0.CD18-redhat-SNAPSHOT//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70)
> at org.wildfly.clustering.service@7.3.0.CD18-redhat-SNAPSHOT//org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$start$0(AsyncServiceConfigurator.java:117)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:116)
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:58)
> at org.wildfly.clustering.service@7.3.0.CD18-redhat-SNAPSHOT//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67)
> ... 7 more
> Caused by: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> at java.base/java.security.KeyPairGenerator.getInstance(KeyPairGenerator.java:236)
> at org.jgroups@4.1.4.Final//org.jgroups.protocols.ASYM_ENCRYPT.initKeyPair(ASYM_ENCRYPT.java:507)
> at org.jgroups@4.1.4.Final//org.jgroups.protocols.ASYM_ENCRYPT.init(ASYM_ENCRYPT.java:105)
> at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:861)
> at org.jgroups@4.1.4.Final//org.jgroups.stack.ProtocolStack.init(ProtocolStack.java:849)
> at org.jgroups(a)4.1.4.Final//org.jgroups.JChannel.<init>(JChannel.java:155)
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:116)
> at org.jboss.as.clustering.jgroups@7.3.0.CD18-redhat-SNAPSHOT//org.jboss.as.clustering.jgroups.subsystem.ChannelServiceConfigurator.get(ChannelServiceConfigurator.java:96)
> ... 9 more
> 13:10:51,021 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 81) WFLYMSGAMQ0002: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory
> 13:10:51,043 INFO [org.wildfly.extension.messaging-activemq] (ServerService Thread Pool -- 83) WFLYMSGAMQ0002: Bound messaging object to jndi name java:/ConnectionFactory
> 13:10:51,108 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0007: Registered connection factory java:/JmsXA
> 13:10:51,269 INFO [org.apache.activemq.artemis.ra] (MSC service thread 1-1) AMQ151007: Resource adaptor started
> 13:10:51,269 INFO [org.jboss.as.connector.services.resourceadapters.ResourceAdapterActivatorService$ResourceAdapterActivator] (MSC service thread 1-1) IJ020002: Deployed: file://RaActivatoractivemq-ra
> 13:10:51,271 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0002: Bound JCA ConnectionFactory [java:/JmsXA]
> 13:10:51,271 INFO [org.jboss.as.connector.deployment] (MSC service thread 1-1) WFLYJCA0118: Binding connection factory named java:/JmsXA to alias java:jboss/DefaultJMSConnectionFactory
> 13:10:51,440 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.clustering.jgroups.channel.ee" => "java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> Caused by: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> Caused by: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available"}}
> 13:10:51,455 INFO [org.jboss.as.server] (ServerService Thread Pool -- 45) WFLYSRV0010: Deployed "ROOT.war" (runtime-name : "ROOT.war")
> 13:10:51,458 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service org.wildfly.clustering.jgroups.channel.ee: java.lang.IllegalStateException: java.security.NoSuchAlgorithmException: true KeyPairGenerator not available
> WFLYCTL0448: 38 additional services are down due to their dependencies being missing or failed
> 13:10:51,569 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:10:51,579 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://0.0.0.0:9990/management
> 13:10:51,579 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0054: Admin console is not enabled
> 13:10:51,579 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: JBoss EAP CD 7.3.0.CD18 (WildFly Core 10.0.1.Final-redhat-SNAPSHOT) started (with errors) in 9553ms - Started 476 of 835 services (35 services failed or missing dependencies, 541 services are lazy, passive or on-demand)
> ERROR *** JBossAS wrapper process (1) received TERM signal ***
> {code}
> The same deployment with same deployment config will not fail with previous images.
> There's an actual difference in outputted JGroups configuration:
> {code:title=7.3.0.Beta} <protocol type="ASYM_ENCRYPT">
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> <property name="change_key_on_leave">true</property>
> </protocol>
> {code}
> {code:title=New image} <protocol type="org.jgroups.protocols.ASYM_ENCRYPT">
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">true</property>
> </protocol>{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 7 months