[JBoss JIRA] (DROOLS-4555) Importing DMN model causes NullPointerException
by Jonas Tamimi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4555?page=com.atlassian.jira.plugi... ]
Jonas Tamimi updated DROOLS-4555:
---------------------------------
Description:
Hi,
this is my first issue, so I hope I did everything right. We have been using version 7.21.0.Final of Drools for the last few months. A few weeks ago we switched to the latest version and could not import a few of our decision models (.dmn) anymore. According to our own research the bug seems to be present since 7.22.0.t042 and is still present in the latest snapshot.
This is the relevant logging output: [https://gist.github.com/oas/ec0f70585411d8c3f0266b7d2fd02ebc|https://gist...]
I tried to narrow down the exception and it seems to be in the method {{checkVariableName}} of {{org.kie.dmn.feel.parser.feel11.FEELParser}}. {{errorChecker.hasErrors()}} is false, but it is not catched by the if statement in line 111. Because of this, {{errorChecker.getErrors()}} returns null instead of a {{List<FEELEvent>}}.
The method checkVariableName in {{org.kie.dmn.core.compiler.DMNCompilerHelper}}, assumes that a list will be returned and calls {{isEmpty()}}. This throws the {{NullPointerException}}.
was:
Hi,
this is my first issue, so I hope I did everything right. We have been using version 7.21.0.Final of Drools for the last few months. A few weeks ago we switched to the latest version and could not import a few of our decision models (.dmn) anymore. According to our own research the bug seems to be present since 7.22.0.t042 and is still present in the latest snapshot.
This is the relevant logging output: [https://gist.github.com/oas/ec0f70585411d8c3f0266b7d2fd02ebc|https://gist...]
I tried to narrow down the exception and it seems to be in the method {{checkVariableName}} of {{org.kie.dmn.feel.parser.feel11.FEELParser}}. {{errorChecker.hasErrors()}} is false, but it is not catched by the if statement in line 111. Because of this, {{errorChecker.getErrors()}} returns null instead of a {{List<FEELEvent>}}.
The method checkVariableName in _org.kie.dmn.core.compiler.DMNCompilerHelper_, assumes that a list will be returned and calls {{isEmpty()}}. This throws the {{NullPointerException}}.
> Importing DMN model causes NullPointerException
> -----------------------------------------------
>
> Key: DROOLS-4555
> URL: https://issues.jboss.org/browse/DROOLS-4555
> Project: Drools
> Issue Type: Bug
> Reporter: Jonas Tamimi
> Assignee: Mario Fusco
> Priority: Major
>
> Hi,
> this is my first issue, so I hope I did everything right. We have been using version 7.21.0.Final of Drools for the last few months. A few weeks ago we switched to the latest version and could not import a few of our decision models (.dmn) anymore. According to our own research the bug seems to be present since 7.22.0.t042 and is still present in the latest snapshot.
> This is the relevant logging output: [https://gist.github.com/oas/ec0f70585411d8c3f0266b7d2fd02ebc|https://gist...]
> I tried to narrow down the exception and it seems to be in the method {{checkVariableName}} of {{org.kie.dmn.feel.parser.feel11.FEELParser}}. {{errorChecker.hasErrors()}} is false, but it is not catched by the if statement in line 111. Because of this, {{errorChecker.getErrors()}} returns null instead of a {{List<FEELEvent>}}.
> The method checkVariableName in {{org.kie.dmn.core.compiler.DMNCompilerHelper}}, assumes that a list will be returned and calls {{isEmpty()}}. This throws the {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4555) Importing DMN model causes NullPointerException
by Jonas Tamimi (Jira)
Jonas Tamimi created DROOLS-4555:
------------------------------------
Summary: Importing DMN model causes NullPointerException
Key: DROOLS-4555
URL: https://issues.jboss.org/browse/DROOLS-4555
Project: Drools
Issue Type: Bug
Reporter: Jonas Tamimi
Assignee: Mario Fusco
Hi,
this is my first issue, so I hope I did everything right. We have been using version 7.21.0.Final of Drools for the last few months. A few weeks ago we switched to the latest version and could not import a few of our decision models (.dmn) anymore. According to our own research the bug seems to be present since 7.22.0.t042 and is still present in the latest snapshot.
This is the relevant logging output: [https://gist.github.com/oas/ec0f70585411d8c3f0266b7d2fd02ebc|https://gist...]
I tried to narrow down the exception and it seems to be in the method {{checkVariableName}} of {{org.kie.dmn.feel.parser.feel11.FEELParser}}. {{errorChecker.hasErrors()}} is false, but it is not catched by the if statement in line 111. Because of this, {{errorChecker.getErrors()}} returns null instead of a {{List<FEELEvent>}}.
The method checkVariableName in _org.kie.dmn.core.compiler.DMNCompilerHelper_, assumes that a list will be returned and calls {{isEmpty()}}. This throws the {{NullPointerException}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4518) Implement UX styles for Test Coverage Report
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4518?page=com.atlassian.jira.plugi... ]
Yeser Amer updated DROOLS-4518:
-------------------------------
Attachment: Screenshot from 2019-09-20 16-10-22.png
> Implement UX styles for Test Coverage Report
> --------------------------------------------
>
> Key: DROOLS-4518
> URL: https://issues.jboss.org/browse/DROOLS-4518
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2019-09-10 at 9.35.23 AM.png, Screen Shot 2019-09-10 at 9.37.02 AM.png, Screenshot from 2019-09-10 17-52-00.png, Screenshot from 2019-09-20 12-30-01.png, Screenshot from 2019-09-20 16-05-04.png, Screenshot from 2019-09-20 16-10-22.png, screenshot-1.png
>
>
> The implemented styles for the Test Coverage Report panel do not align with the HTML/CSS provided in jira https://issues.jboss.org/browse/DROOLS-3741.
> The styles used in the current implementation might present usability concerns - the Decision/Scenario list type size is very small and could pose a readability issue. The layout and alignment of the test summary data is difficult to scan, due to the gutter alignment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4518) Implement UX styles for Test Coverage Report
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4518?page=com.atlassian.jira.plugi... ]
Yeser Amer commented on DROOLS-4518:
------------------------------------
I had a discussion with [~srambach] and Liz about this ticket and they reported the following changes to apply to the current situation:
https://docs.google.com/presentation/d/14dfrZnRP-RF5z4-ufee-GMm3flKQVUxhf...
I fixed the test alignment, wrong font type and minor css issues.
Regarding the required change on Donut graph, I afraid it's not feasible implement the required change. I analyzed the current Widget used to draw that graph, and it seems clear to me that it's not possible to customize it in such way.
Then, during a discussion with Liz and Sarah, we agreed to raise this point in the next team meeting, where we will propose the following solutions:
- No changes: leave the Donut graph as it is;
- Remove the graph at all;
- Use a PIE graph, which seems looks better.
You can find attached the screenshots of the resulting of the three possible solutions.
[~tirelli],[~danielezonca] and [~gabriolo] fyi
!Screenshot from 2019-09-20 16-05-04.png|thumbnail!
!Screenshot from 2019-09-20 12-30-01.png|thumbnail!
!Screenshot from 2019-09-20 16-10-22.png|thumbnail!
> Implement UX styles for Test Coverage Report
> --------------------------------------------
>
> Key: DROOLS-4518
> URL: https://issues.jboss.org/browse/DROOLS-4518
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2019-09-10 at 9.35.23 AM.png, Screen Shot 2019-09-10 at 9.37.02 AM.png, Screenshot from 2019-09-10 17-52-00.png, Screenshot from 2019-09-20 12-30-01.png, Screenshot from 2019-09-20 16-05-04.png, Screenshot from 2019-09-20 16-10-22.png, screenshot-1.png
>
>
> The implemented styles for the Test Coverage Report panel do not align with the HTML/CSS provided in jira https://issues.jboss.org/browse/DROOLS-3741.
> The styles used in the current implementation might present usability concerns - the Decision/Scenario list type size is very small and could pose a readability issue. The layout and alignment of the test summary data is difficult to scan, due to the gutter alignment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4518) Implement UX styles for Test Coverage Report
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4518?page=com.atlassian.jira.plugi... ]
Yeser Amer updated DROOLS-4518:
-------------------------------
Attachment: Screenshot from 2019-09-20 12-30-01.png
> Implement UX styles for Test Coverage Report
> --------------------------------------------
>
> Key: DROOLS-4518
> URL: https://issues.jboss.org/browse/DROOLS-4518
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2019-09-10 at 9.35.23 AM.png, Screen Shot 2019-09-10 at 9.37.02 AM.png, Screenshot from 2019-09-10 17-52-00.png, Screenshot from 2019-09-20 12-30-01.png, Screenshot from 2019-09-20 16-05-04.png, screenshot-1.png
>
>
> The implemented styles for the Test Coverage Report panel do not align with the HTML/CSS provided in jira https://issues.jboss.org/browse/DROOLS-3741.
> The styles used in the current implementation might present usability concerns - the Decision/Scenario list type size is very small and could pose a readability issue. The layout and alignment of the test summary data is difficult to scan, due to the gutter alignment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4518) Implement UX styles for Test Coverage Report
by Yeser Amer (Jira)
[ https://issues.jboss.org/browse/DROOLS-4518?page=com.atlassian.jira.plugi... ]
Yeser Amer updated DROOLS-4518:
-------------------------------
Attachment: Screenshot from 2019-09-20 16-05-04.png
> Implement UX styles for Test Coverage Report
> --------------------------------------------
>
> Key: DROOLS-4518
> URL: https://issues.jboss.org/browse/DROOLS-4518
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam
> Attachments: Screen Shot 2019-09-10 at 9.35.23 AM.png, Screen Shot 2019-09-10 at 9.37.02 AM.png, Screenshot from 2019-09-10 17-52-00.png, Screenshot from 2019-09-20 16-05-04.png, screenshot-1.png
>
>
> The implemented styles for the Test Coverage Report panel do not align with the HTML/CSS provided in jira https://issues.jboss.org/browse/DROOLS-3741.
> The styles used in the current implementation might present usability concerns - the Decision/Scenario list type size is very small and could pose a readability issue. The layout and alignment of the test summary data is difficult to scan, due to the gutter alignment.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (JGRP-2382) JGroups version 4.0.13.Final.jar is causing memory leaks
by Rashmi Acharya (Jira)
[ https://issues.jboss.org/browse/JGRP-2382?page=com.atlassian.jira.plugin.... ]
Rashmi Acharya commented on JGRP-2382:
--------------------------------------
Hi Bela,
Customer is making it as Sev-1 , their production and test are getting affected. Can we get into a call with us now to discuss next steps ?
> JGroups version 4.0.13.Final.jar is causing memory leaks
> --------------------------------------------------------
>
> Key: JGRP-2382
> URL: https://issues.jboss.org/browse/JGRP-2382
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.13
> Environment: AIX machine 7.1 with JDK 1.8
> Reporter: Rashmi Acharya
> Assignee: Bela Ban
> Priority: Major
> Attachments: dumps_TEST_node1_20190918_after_3_hours.zip, dumps_TEST_node1_20190918_right_after_restart.zip, dumps_TEST_node2_20190918_after_3_hours.zip, dumps_TEST_node2_20190918_right_after_restart.zip
>
>
> We are observing a constant memory growth and leak with JGroup version 4.0.13 ..
> One of our customer is having two node cluster environment and in one node we are observing org.Group.Messages which contain org.groups.Header and org.groups.Stack.ipAddress objects.. these are not getting cleared from memory..
> We dont see any exception related to Jgroups from logs and but it is causing a gradual emory growth and OOM.
> Here is the Jgroups cluster configuration we have:
> dynamic.cluster.property_string
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT2;"/>
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000" />
> <FD_ALL timeout="20000" interval="15000"/>
> <FD_SOCK/>
> <FD timeout="5000" max_tries="48" />
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3/>
> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000"/>
> <pbcast.GMS print_local_addr="true" join_timeout="15000" />
> </config>
> =================================
> dynamic.cluster.distribution_property_string
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_port="&MULTICAST_NODE_PORT1;" />
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000"/>
> <FD_SOCK/>
> <FD timeout="5000" max_tries="48"/>
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3/>
> <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000" />
> <pbcast.GMS print_local_addr="true" join_timeout="5000"/>
> </config>
> ================================
> dynamic.cluster.lock.protocolStack
> <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd">
> <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT3;"/>
> <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/>
> <MERGE3 min_interval="3000" max_interval="5000"/>
> <FD_ALL timeout="20000" interval="5000"/>
> <FD timeout="5000" max_tries="48"/>
> <VERIFY_SUSPECT timeout="1500"/>
> <BARRIER/>
> <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/>
> <UNICAST3 /> <pbcast.STABLE desired_avg_gossip="20000" />
> <pbcast.GMS print_local_addr="true" join_timeout="5000"/>
> <FRAG2 frag_size="8096"/>
> <CENTRAL_LOCK2/>
> </config>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFWIP-206) scale down isn't successful when there are in-doubt transaction on pod
by Ondrej Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFWIP-206?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka commented on WFWIP-206:
----------------------------------------
ok, I fixed a trouble of not finishing the transaction and I put the code as commit to branch https://github.com/ochaloup/wildfly-operator/tree/issue72-pending-contain...
The operator is built at {{quay.io/ochaloup/wildfly-operator:20190920}}.
I'm not going to close this issue right now as even the test passes (after ~2min of processing, possibly some more tuning is needed) then there is left data at the {{tx-client-0}} at place {{/opt/eap/standalone/data/ejb-xa-recovery/20005_00000000000000000000ffffac11000c197429375d84c5450000001374782d636c69656e742d30_00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000}}. That's not good as I have no idea why it is so. Maybe [~tomekadamski] could take a look?
> scale down isn't successful when there are in-doubt transaction on pod
> ----------------------------------------------------------------------
>
> Key: WFWIP-206
> URL: https://issues.jboss.org/browse/WFWIP-206
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Environment: operator, built from [1984d98154f11a7473be065e4ae7f54b1812c9b0|https://github.com/wildfly/wildf...] :
> {noformat}
> docker-registry.engineering.redhat.com/jbossqe-eap/wildfly-operator:latest
> {noformat}
> EAP image:
> {noformat}
> docker-registry.engineering.redhat.com/ochaloup/wildfly18-snapshot:190909...
> {noformat}
> Reporter: Martin Simka
> Assignee: Ondrej Chaloupka
> Priority: Blocker
> Labels: operator
>
> 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
> 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. But scale down never completes.
> Log from operator:
> {noformat}
> {"level":"info","ts":1568905676.6303623,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905676.7313502,"logger":"controller_wildflyserver","msg":"Enabling recovery listener for processing scaledown at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905679.4325309,"logger":"controller_wildflyserver","msg":"Query to find the transaction recovery port to force scan at pod tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905686.7914035,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"info","ts":1568905702.0583296,"logger":"controller_wildflyserver","msg":"In-doubt transactions in object store","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","Message":"Recovery scan to be invoked as the transaction log storage is not empty for pod scaling down pod tx-server-0, transaction list: map[0:ffffac11000a:991c183:5d8399a1:13:map[age-in-seconds:23 id:0:ffffac11000a:991c183:5d8399a1:13 jmx-name:<nil> participants:map[java:/MockXAResource:map[eis-product-name:MockXAResource Test eis-product-version:0.1.Mock jmx-name:<nil> jndi-name:java:/MockXAResource status:PREPARED type:/StateManager/AbstractRecord/XAResourceRecord]] type:StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA]]"}
> {"level":"info","ts":1568905711.1034026,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.103548,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.109706,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.2608829,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Error to get response for command SCAN sending to 172.17.0.10:4712, error: EOF]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.2609518,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2609615,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795022,"logger":"controller_wildflyserver","msg":"Updating StatefulSet to be up to date with the WildFlyServer Spec","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.2795491,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905711.2796504,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905711.2937052,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905711.294249,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905711.294342,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905711.294417,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"error","ts":1568905711.311673,"logger":"controller_wildflyserver","msg":"Failed to Update StatefulSet.","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"error","ts":1568905711.311745,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"msimka-namespace/tx-server","error":"Operation cannot be fulfilled on statefulsets.apps \"tx-server\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3137681,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"msimka-namespace","Request.Name":"tx-server"}
> {"level":"info","ts":1568905712.3139439,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod Name":"tx-server-0","IP Address":"172.17.0.10"}
> {"level":"info","ts":1568905712.3253288,"logger":"controller_wildflyserver","msg":"Executing recovery scan at tx-server-0","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Pod IP":"172.17.0.10","Recovery port":4712}
> {"level":"error","ts":1568905712.3255754,"logger":"controller_wildflyserver","msg":"Failures during scaling down recovery processing","Request.Namespace":"msimka-namespace","Request.Name":"tx-server","Desired replica size":0,"Number of pods to be removed":1,"error":"Found 1 errors:\n [[Failed to run transaction recovery scan for scaling down pod tx-server-0. Please, verify the pod log file. Error: Cannot process TCP connection to 172.17.0.10:4712, error: dial tcp 172.17.0.10:4712: connect: connection refused]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
> {"level":"info","ts":1568905712.3256311,"logger":"controller_wildflyserver","msg":"Scaling down statefulset by verification if pods are clean by recovery","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {"level":"info","ts":1568905712.3256419,"logger":"controller_wildflyserver","msg":"Statefulset was not fully scaled to the desired replica size 0 while StatefulSet is to be at size 1. Some pods were not cleaned by recovery. Verify status of the WildflyServer tx-server","StatefulSet.Namespace":"msimka-namespace","StatefulSet.Name":"tx-server"}
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months