[JBoss JIRA] (DROOLS-4632) Optimize single pattern forall statement
by Mario Fusco (Jira)
Mario Fusco created DROOLS-4632:
-----------------------------------
Summary: Optimize single pattern forall statement
Key: DROOLS-4632
URL: https://issues.jboss.org/browse/DROOLS-4632
Project: Drools
Issue Type: Enhancement
Reporter: Mario Fusco
Assignee: Mario Fusco
At the moment a single pattern forall statement like
{code}
forall( Type( constraints ) )
{code}
it is automatically rewritten as
{code}
forall( $t : Type() Type( this == $t, constraints ) )
{code}
and then implemented with 2 not nodes and join. It would be much faster to rewrite it as
{code}
not( Type( !constraints ) )
{code}
and then evaluate it with one single not node.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-241) scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFWIP-241?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka commented on WFWIP-241:
----------------------------------------
This issue connects to a WFC-77 but only in regards of a similar test case and in fact that the folder {{/opt/eap/standalone/data/ejb-xa-recovery}} is not cleaned during recovery and as it's not cleaned it prevents the scaledown could be processed.
But this issue has nothing with an error in the WFTC component (as it's in big probability the case of the WFTC-77). The trouble is that the {{tx-client}} has no idea on how to finish with the {{ejb-xa-recovery}} records. It does not know if the {{tx-server}} was cleanly scaled-down (in such case the record may be removed) or if the {{tx-server}} is temporarily down and it will be resurrected and some work is needed to be done (in which case the record has to be left living and the {{tx-client}} can't be scaled-down).
The scenario is following.
{{tx-client}} runs the 2PC {{PREPARE}} at the {{tx-server}}. {{tx-server}} calss prepare at the remote resource (e.g. database) and crashes. The 2PC {{PREPARE}} phase was not finished at the {{tx-server}} and thus the rollback is assumed.
After the restart of the {{tx-server}} the recovery process may rollback all data in the database as the rollback is assumed (the prepare was not finished, there is no promise about finishing with commit). The {{tx-server}} cleans all resources and is permitted to scaled-down (all data was rolled-back, data consistency is fine).
But now when {{tx-server}} went away the {{tx-client}} stays with the record at the {{ejb-xa-recovery}}. When the {{tx-server}} will be restarted and availale the {{tx-client}} would call {{recover}}, finds out the {{tx-server}} has no indoubt work and the record would be deleted.
But now the {{tx-server}} is shutdown and {{tx-client}} has no idea how to finish with the record. There needs to be some 3rd party process from e.g. WFLY operator to say that there is no need of further existence of the record. For this would working probably some new {{jboss-cli.sh}} command would be needed. We need to find out what are the unfinished remote resources from perspective of WFTC and then we need to say that those which are still in the repository may be ignored as servers are already not in existence.
> scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFWIP-241
> URL: https://issues.jboss.org/browse/WFWIP-241
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Major
> Labels: operator
>
> While testing tx recovery in OpenShift I see that scale down of client pod that has transaction in-doubt on it isn't successful when there is server pod that is part of transaction which isn't reachable
> 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
> *testTxStatelessServerSecondPrepareJvmHaltScaleDownClient*
> Test workflow:
> - ejb server XA resource crashes JVM on tx-server pod
> - label "{{wildfly.org/operated-by-headless}}" of server pod is changed, which causes that server isn't reachable
> - tx-server pod is scaled down
> - tx-client pod is scaled down
> *scale down of client pod hangs*
> {noformat}
> {"level":"info","ts":1570636701.0314589,"logger":"wildflyserver_controller","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"}
> {"level":"info","ts":1570636701.0314867,"logger":"wildflyserver_controller","msg":"Statefulset was not scaled to the desired replica size 0 (current StatefulSet size: 1). Transaction recovery scaledown process has not cleaned all pods. Please, check status of the WildflyServer tx-client","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-client"}
> {"level":"info","ts":1570636703.5918324,"logger":"wildflyserver_controller","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-client"}
> {"level":"info","ts":1570636703.5919785,"logger":"wildlfyserver_resources","msg":"Getting resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"}
> {"level":"info","ts":1570636703.5920458,"logger":"wildlfyserver_resources","msg":"Got resource","WildFlyServer.Namespace":"msimka-namespace","WildFlyServer.Name":"tx-client","Resource.Name":"tx-client"}
> {"level":"info","ts":1570636703.5921679,"logger":"wildflyserver_controller","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","IP Address":"10.128.1.34","Pod State":"SCALING_DOWN_RECOVERY_DIRTY","Pod Phase":"Running"}
> {"level":"info","ts":1570636703.5922475,"logger":"wildflyserver_controller","msg":"Recovery properties at pod were already defined. Skipping server restart.","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0"}
> {"level":"info","ts":1570636703.5971646,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712}
> {"level":"info","ts":1570636709.162107,"logger":"wildflyserver_controller","msg":"Executing recovery scan at tx-client-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod IP":"10.128.1.34","Recovery port":4712}
> {"level":"info","ts":1570636714.7187033,"logger":"wildflyserver_controller","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-client","Pod Name":"tx-client-0","Message":"WildFly Transaction Client data dir is not empty and scaling down of the pod 'tx-client-0' will be retried.Wildfly Transacton Client data dir path '/opt/eap/standalone/data/ejb-xa-recovery', output listing: 20005_00000000000000000000ffff0a80012251f788695d9e026b0000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000\n"}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-244) Duplicate warning messages in the console
by Yeray Borges (Jira)
[ https://issues.jboss.org/browse/WFWIP-244?page=com.atlassian.jira.plugin.... ]
Yeray Borges updated WFWIP-244:
-------------------------------
Steps to Reproduce: docker run -it --rm jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:18.0 (was: docker run -it --rm --label working \
jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:18.0)
> Duplicate warning messages in the console
> -----------------------------------------
>
> Key: WFWIP-244
> URL: https://issues.jboss.org/browse/WFWIP-244
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Yeray Borges
> Assignee: Yeray Borges
> Priority: Major
>
> Warning messages are shown twice before and after embedded server configuration runs, see for example the warnings related to AMQ embedded server:
> {noformat}
> INFO Configuring JGroups cluster traffic encryption protocol to SYM_ENCRYPT.
> WARN Detected missing JGroups encryption configuration, the communication within the cluster WILL NOT be encrypted.
> WARN No password defined for JGroups cluster. AUTH protocol will be disabled. Please define JGROUPS_CLUSTER_PASSWORD.
> WARN Environment variable OPENSHIFT_KUBE_PING_NAMESPACE undefined. Clustering will be unavailable. Please refer to the documentation for configuration.
> INFO Configuring JGroups discovery protocol to kubernetes.KUBE_PING
> INFO Using PicketBox SSL configuration.
> INFO Access log is disabled, ignoring configuration.
> WARN Configuration of an embedded messaging broker within the appserver is enabled but is not recommended. Support for such a configuration will be removed in a future release.
> WARN If you are not configuring messaging destinations, to disable configuring an embedded messaging broker set the DISABLE_EMBEDDED_JMS_BROKER environment variable to true.
> Configuring the server using embedded server
> Duration: 3643 milliseconds
> WARN Configuration of an embedded messaging broker within the appserver is enabled but is not recommended. Support for such a configuration will be removed in a future release.
> WARN If you are not configuring messaging destinations, to disable configuring an embedded messaging broker set the DISABLE_EMBEDDED_JMS_BROKER environment variable to true.
> INFO Running jboss-eap-7-tech-preview/eap-cd-openshift-rhel8 image, version 18.0
> -XX:+UseParallelOldGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -XX:+ExitOnOutOfMemoryError
> =========================================================================
> JBoss Bootstrap Environment
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFWIP-244) Duplicate warning messages in the console
by Yeray Borges (Jira)
Yeray Borges created WFWIP-244:
----------------------------------
Summary: Duplicate warning messages in the console
Key: WFWIP-244
URL: https://issues.jboss.org/browse/WFWIP-244
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Yeray Borges
Assignee: Yeray Borges
Warning messages are shown twice before and after embedded server configuration runs, see for example the warnings related to AMQ embedded server:
{noformat}
INFO Configuring JGroups cluster traffic encryption protocol to SYM_ENCRYPT.
WARN Detected missing JGroups encryption configuration, the communication within the cluster WILL NOT be encrypted.
WARN No password defined for JGroups cluster. AUTH protocol will be disabled. Please define JGROUPS_CLUSTER_PASSWORD.
WARN Environment variable OPENSHIFT_KUBE_PING_NAMESPACE undefined. Clustering will be unavailable. Please refer to the documentation for configuration.
INFO Configuring JGroups discovery protocol to kubernetes.KUBE_PING
INFO Using PicketBox SSL configuration.
INFO Access log is disabled, ignoring configuration.
WARN Configuration of an embedded messaging broker within the appserver is enabled but is not recommended. Support for such a configuration will be removed in a future release.
WARN If you are not configuring messaging destinations, to disable configuring an embedded messaging broker set the DISABLE_EMBEDDED_JMS_BROKER environment variable to true.
Configuring the server using embedded server
Duration: 3643 milliseconds
WARN Configuration of an embedded messaging broker within the appserver is enabled but is not recommended. Support for such a configuration will be removed in a future release.
WARN If you are not configuring messaging destinations, to disable configuring an embedded messaging broker set the DISABLE_EMBEDDED_JMS_BROKER environment variable to true.
INFO Running jboss-eap-7-tech-preview/eap-cd-openshift-rhel8 image, version 18.0
-XX:+UseParallelOldGC -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=20 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -XX:+ExitOnOutOfMemoryError
=========================================================================
JBoss Bootstrap Environment
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-1066:
---------------------------------
Priority: Minor (was: Major)
> Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1066
> URL: https://issues.jboss.org/browse/WFLY-1066
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Management
> Environment: Server running in Domain mode
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Priority: Minor
> Labels: clustering, domain, jgroups
>
> It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode.
> All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration.
> The domain server will receive the information if a host-controller enrol and register server to a clustered server-group.
> So the configuration of the initial_hosts can be done automatically to avoid old entries which cause unnecessary checks and ensure that all active servers are known.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-1066:
---------------------------------
Component/s: Clustering
> Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1066
> URL: https://issues.jboss.org/browse/WFLY-1066
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Management
> Environment: Server running in Domain mode
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
> Priority: Major
> Labels: clustering, domain, jgroups
>
> It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode.
> All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration.
> The domain server will receive the information if a host-controller enrol and register server to a clustered server-group.
> So the configuration of the initial_hosts can be done automatically to avoid old entries which cause unnecessary checks and ensure that all active servers are known.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-1066:
------------------------------------
Assignee: Paul Ferraro (was: Jason Greene)
> Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1066
> URL: https://issues.jboss.org/browse/WFLY-1066
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Management
> Environment: Server running in Domain mode
> Reporter: Wolf-Dieter Fink
> Assignee: Paul Ferraro
> Priority: Major
> Labels: clustering, domain, jgroups
>
> It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode.
> All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration.
> The domain server will receive the information if a host-controller enrol and register server to a clustered server-group.
> So the configuration of the initial_hosts can be done automatically to avoid old entries which cause unnecessary checks and ensure that all active servers are known.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months