September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBCLUSTER-316) remoteingress to patch ClusterIngress with certificate bundle

by James Harrington (Jira)

James Harrington created JBCLUSTER-316: ------------------------------------------ Summary: remoteingress to patch ClusterIngress with certificate bundle Key: JBCLUSTER-316 URL: https://issues.redhat.com/browse/JBCLUSTER-316 Project: JBoss Clustering Issue Type: Feature Request Reporter: James Harrington Assignee: Paul Ferraro Once a cluster is installed Hive should patch a cluster's ingresscontroller with the new certificate bundle from Lets Encrypt to enable the console URL to work as soon as those certificates are available. Hive's remoteingress controller [here|https://github.com/openshift/hive/blob/master/pkg/controller/remotei...] used to do exactly this by creating a new ingresscontroller object in the openshift-ingress-operator namespace but raced with the cloud-ingress-operator to manage it so it was disabled [here|https://gitlab.cee.redhat.com/service/app-interface/-/blob/master/da...]. I’m not sure if we can replace creating the entire ingresscontroller or just patch the new `.spec.defaultCertificate` to be the new certificate bundle. The piece I don’t know about is if the cluster-ingress-operator will load in the new certificates or do we have to completely replace the object? For example cloud-ingress-operator has to replace the entire ingresscontroller CR to have it change the load balancer from external to internal, I suspect the cert patch will work since the cert isn’t terminated on the ELB. The defaultCertificate ref is in the ingresscontroller spec Hive was updating it [here|https://github.com/openshift/hive/blob/master/pkg/controller/remotei...] This controller likely raced with cloud-ingress-operator because they were both watching and reconciling the same object. Maybe we could enable this controller but disable the watch when “ActiveAPIURLOverride” is set in the ClusterDeployment? Though that doesn’t feel right. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5668) Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories

by Sylvain Lemoine (Jira)

[ https://issues.redhat.com/browse/DROOLS-5668?page=com.atlassian.jira.plug... ] Sylvain Lemoine edited comment on DROOLS-5668 at 9/24/20 4:30 PM: ------------------------------------------------------------------ ok thanks you for considering this issue was (Author: slem1): ok thanks you for considering this issue as deserialization of kieSession from previous drools version is pretty critical for our project. > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-5668 > URL: https://issues.redhat.com/browse/DROOLS-5668 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.43.1.Final > Reporter: Sylvain Lemoine > Assignee: Mario Fusco > Priority: Major > Attachments: drools-node-memories-serialization.tar.gz > > > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization > of node memories. For instance it happens if a serialization has been done with earliest version and accumulate node. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5668) Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories

by Sylvain Lemoine (Jira)

[ https://issues.redhat.com/browse/DROOLS-5668?page=com.atlassian.jira.plug... ] Sylvain Lemoine edited comment on DROOLS-5668 at 9/24/20 4:29 PM: ------------------------------------------------------------------ ok thanks you for considering this issue as deserialization of kieSession from previous drools version is pretty critical for our project. was (Author: slem1): ok thanks you for considering this issue as deserialization of kieSession from previous drools version is pretty critical for our project. Anyway, I push a bit further my investigations and simply letting pass accumulate node as I did was obviously wrong due to the way tuple for dormant activation are now fully serialized (A), and it takes part in the definition of the activationkey in dormantActivations. As (A) is not present in earliest 7.x serialized session, the following piece of code is not able to filter dormant activation: {code:java} RuleImpl rule = activation.getRule(); ActivationKey activationKey = PersisterHelper.hasNodeMemory( rtn ) ? PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple().toObjects(true)) : PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple() ); this.tuplesCache.put( activationKey, activation.getTuple() ); return !dormantActivations.contains(activationKey);{code} > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-5668 > URL: https://issues.redhat.com/browse/DROOLS-5668 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.43.1.Final > Reporter: Sylvain Lemoine > Assignee: Mario Fusco > Priority: Major > Attachments: drools-node-memories-serialization.tar.gz > > > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization > of node memories. For instance it happens if a serialization has been done with earliest version and accumulate node. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5668) Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories

by Sylvain Lemoine (Jira)

[ https://issues.redhat.com/browse/DROOLS-5668?page=com.atlassian.jira.plug... ] Sylvain Lemoine edited comment on DROOLS-5668 at 9/24/20 4:28 PM: ------------------------------------------------------------------ ok thanks you for considering this issue as deserialization of kieSession from previous drools version is pretty critical for our project. Anyway, I push a bit further my investigations and simply letting pass accumulate node as I did was obviously wrong due to the way tuple for dormant activation are now fully serialized (A), and it takes part in the definition of the activationkey in dormantActivations. As (A) is not present in earliest 7.x serialized session, the following piece of code is not able to filter dormant activation: {code:java} RuleImpl rule = activation.getRule(); ActivationKey activationKey = PersisterHelper.hasNodeMemory( rtn ) ? PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple().toObjects(true)) : PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple() ); this.tuplesCache.put( activationKey, activation.getTuple() ); return !dormantActivations.contains(activationKey);{code} was (Author: slem1): I push a bit further my investigations, seems due to the way tuple for dormant activation are now fully serialized (A), and it takes part in the definition of the activationkey in dormantActivations. As (A) is not present in earliest 7.x serialized session, the following piece of code is not able to filter dormant activation: {code:java} RuleImpl rule = activation.getRule(); ActivationKey activationKey = PersisterHelper.hasNodeMemory( rtn ) ? PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple().toObjects(true)) : PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple() ); this.tuplesCache.put( activationKey, activation.getTuple() ); return !dormantActivations.contains(activationKey);{code} > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-5668 > URL: https://issues.redhat.com/browse/DROOLS-5668 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.43.1.Final > Reporter: Sylvain Lemoine > Assignee: Mario Fusco > Priority: Major > Attachments: drools-node-memories-serialization.tar.gz > > > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization > of node memories. For instance it happens if a serialization has been done with earliest version and accumulate node. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5668) Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories

by Sylvain Lemoine (Jira)

[ https://issues.redhat.com/browse/DROOLS-5668?page=com.atlassian.jira.plug... ] Sylvain Lemoine commented on DROOLS-5668: ----------------------------------------- I push a bit further my investigations, seems due to the way tuple for dormant activation are now fully serialized (A), and it takes part in the definition of the activationkey in dormantActivations. As (A) is not present in earliest 7.x serialized session, the following piece of code is not able to filter dormant activation: {code:java} RuleImpl rule = activation.getRule(); ActivationKey activationKey = PersisterHelper.hasNodeMemory( rtn ) ? PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple().toObjects(true)) : PersisterHelper.createActivationKey( rule.getPackageName(), rule.getName(), activation.getTuple() ); this.tuplesCache.put( activationKey, activation.getTuple() ); return !dormantActivations.contains(activationKey);{code} > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization of node memories > ------------------------------------------------------------------------------------------------------------------------------------------------------ > > Key: DROOLS-5668 > URL: https://issues.redhat.com/browse/DROOLS-5668 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.43.1.Final > Reporter: Sylvain Lemoine > Assignee: Mario Fusco > Priority: Major > Attachments: drools-node-memories-serialization.tar.gz > > > Latest drools minor versions broke deserialization from earliest 7.x version due to changes made on the serialization/deserialization > of node memories. For instance it happens if a serialization has been done with earliest version and accumulate node. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5134) AuditLogToTLSSyslogTestCase stucks with oracle JDK 11

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFCORE-5134?page=com.atlassian.jira.plug... ] Sonia Zaldana commented on WFCORE-5134: --------------------------------------- The test case passes with JDK13+ and with JDK 11.0.7. It hangs intermittently with JDK 11.0.8. Given these findings, it seems like the hang is due to a JDK issue and perhaps it may be related to the fix for [https://bugs.openjdk.java.net/browse/JDK-8219991] [~ropalka], would you happen to have any thoughts on this? > AuditLogToTLSSyslogTestCase stucks with oracle JDK 11 > ----------------------------------------------------- > > Key: WFCORE-5134 > URL: https://issues.redhat.com/browse/WFCORE-5134 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Priority: Major > > I am using oracle JDK 11, the test get stucks in tear down attempting to execute server tearDown action. I noticed that this test is not run on JDK12 due to a deadlock. The observed problem smells deadlock although jstack doesn't report any. > JDK: > java 11.0.8 2020-07-14 LTS > Java(TM) SE Runtime Environment 18.9 (build 11.0.8+10-LTS) > Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.8+10-LTS, mixed mode) > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13897?page=com.atlassian.jira.plugi... ] Paul Ferraro reassigned WFLY-13897: ----------------------------------- Assignee: Radoslav Husar (was: Paul Ferraro) > infinispan-server instances provisioned by testsuite never shutdown > ------------------------------------------------------------------- > > Key: WFLY-13897 > URL: https://issues.redhat.com/browse/WFLY-13897 > Project: WildFly > Issue Type: Bug > Components: Clustering, Test Suite > Affects Versions: 21.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > > Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13897) infinispan-server instances provisioned by testsuite never shutdown

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-13897: ----------------------------------- Summary: infinispan-server instances provisioned by testsuite never shutdown Key: WFLY-13897 URL: https://issues.redhat.com/browse/WFLY-13897 Project: WildFly Issue Type: Bug Components: Clustering, Test Suite Affects Versions: 21.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro Running the clustering testsuite locally leaves 9 instances of infinispan-server running. This wreaks havoc on the CI, which will remain running until the VM shuts down. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5671) [DMN Designer] Text annotation causes unexpected system error

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-5671?page=com.atlassian.jira.plug... ] Guilherme Gomes closed DROOLS-5671. ----------------------------------- Resolution: Duplicate Issue This JIRA represents the same issue reported on https://issues.redhat.com/browse/DROOLS-5667 and it's addressed by this PR https://github.com/kiegroup/kie-wb-common/pull/3433 > [DMN Designer] Text annotation causes unexpected system error > ------------------------------------------------------------- > > Key: DROOLS-5671 > URL: https://issues.redhat.com/browse/DROOLS-5671 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.44.0.Final > Reporter: Lubomír Terifaj > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Creating Text annotation causes unexpected system error. > Error details: > {code:java} > Uncaught exception: Exception caught: CDI Event exception: CommandType=CDIEvent, BeanType=org.kie.workbench.common.stunner.core.client.canvas.controls.event.BuildCanvasShapeEvent, BeanReference=BuildCanvasShapeEvent [definition=org.kie.workbench.common.dmn.api.definition.model.TextAnnotation@85a8abd2, factory=org.kie.workbench.common.dmn.client.shape.factory.DMNShapeFactory@4941, clientX=674, clientY=350], FromClient=1 sent to [unavailable] Caused by: CDI Event exception: CommandType=CDIEvent, BeanType=org.kie.workbench.common.stunner.core.client.canvas.controls.event.BuildCanvasShapeEvent, BeanReference=BuildCanvasShapeEvent [definition=org.kie.workbench.common.dmn.api.definition.model.TextAnnotation@85a8abd2, factory=org.kie.workbench.common.dmn.client.shape.factory.DMNShapeFactory@4941, clientX=674, clientY=350], FromClient=1 sent to [unavailable] Caused by: CDI Event exception: CommandType=CDIEvent, BeanType=org.kie.workbench.common.stunner.core.client.canvas.event.selection.CanvasSelectionEvent, BeanReference=org.kie.workbench.common.stunner.core.client.canvas.event.selection.CanvasSelectionEvent@4bb7, FromClient=1 sent to [unavailable] Caused by: CDI Event exception: CommandType=CDIEvent, BeanType=org.kie.workbench.common.stunner.core.client.canvas.event.selection.CanvasSelectionEvent, BeanReference=org.kie.workbench.common.stunner.core.client.canvas.event.selection.CanvasSelectionEvent@4bb6, FromClient=1 sent to [unavailable] Caused by: (TypeError) : c is null > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13894) Upgrade jboss-ejb-client to 4.0.35.Final

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13894?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13894: ------------------------------ Description: [https://github.com/wildfly/jboss-ejb-client/compare/4.0.34.Final...4.0.35...] Ther real changes are the fixes for the following 2 issues: EJBCLIENT-356 EJB client API blocks invocation until all configured connections are established/discovered EJBCLIENT-376 SessionOpenInvocations are never removed from remote InvocationTracker was:[https://github.com/wildfly/jboss-ejb-client/compare/4.0.34.Final...4... > Upgrade jboss-ejb-client to 4.0.35.Final > ---------------------------------------- > > Key: WFLY-13894 > URL: https://issues.redhat.com/browse/WFLY-13894 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Ivo Studensky > Assignee: Cheng Fang > Priority: Major > Labels: downstream_dependency > Fix For: 21.0.0.Final > > > [https://github.com/wildfly/jboss-ejb-client/compare/4.0.34.Final...4.0.35...] > Ther real changes are the fixes for the following 2 issues: > EJBCLIENT-356 EJB client API blocks invocation until all configured connections are established/discovered > EJBCLIENT-376 SessionOpenInvocations are never removed from remote InvocationTracker -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020