[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 5:25 AM:
------------------------------------------------------------------
Guess my approach was a bit too naive, rules with pending activation during serialization are no longer triggered after deserialization in latest drools version --> I cancel my PR
was (Author: slem1):
Guess my approach was a bit too naive, rules with pending activation during serialization are no longer triggered after deserialization in latest drools version
> 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
[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] I'm not targetting this for Openshift only, as the name suggests the main area of application is Kubernetes! I would not want to get too Openshift specific.
+1 on a warning; ideally only issued if we're running under Openshift, but not under Kubernetes.
[~sebastian.laskawiec] Not sure I understand your last comment. If there is a misconfiguration, JGroups will typically either issue a warning, or not start at all
> 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
[JBoss JIRA] (WFLY-13793) Allow for a remote jms queue / topic not to use legacy amq1 prefix
by Chao Wang (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Chao Wang updated WFLY-13793:
-----------------------------
Summary: Allow for a remote jms queue / topic not to use legacy amq1 prefix (was: Attribute enable-amq1-prefix doesn't work (remote artemis))
> Allow for a remote jms queue / topic not to use legacy amq1 prefix
> ------------------------------------------------------------------
>
> Key: WFLY-13793
> URL: https://issues.redhat.com/browse/WFLY-13793
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS, Management
> Affects Versions: 20.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
>
> I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error:
> {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}}
> \{{{}}
> \{{ "outcome" => "failed",}}
> \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}}
> {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}}
> \{{ "rolled-back" => true}}
> {{}}}
> {quote}
> If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue.
> I also tried to add the attribute manually but it seems it doesn't work:
> {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}}
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years
[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:
-------------------------------------------
[~filippe.spolti] For OpenShift - definitely yes! You shouldn't deploy your applications there. But that's not true for vanilla Kubernetes (or at least I didn't find any documentation discouraging you from doing that). In vanilla Kubernetes, it's just a namespace like any other.
[~belaban] is disabling discovery protocols upon wrong/missing configuration is something we do in JGroups? Whatever we decide to do here, it needs to behave the same way as other protocols.
> 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