[JBoss JIRA] (WFWIP-206) scale down isn't successful when there are in-doubt transaction on pod
by Martin Simka (Jira)
[ https://issues.jboss.org/browse/WFWIP-206?page=com.atlassian.jira.plugin.... ]
Martin Simka commented on WFWIP-206:
------------------------------------
I'm just confirming that with latest operator scale down works, but I see probably the same problem. Transactions aren't commited. When pod is scaled up again, periodic recovery commits them.
> 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
[JBoss JIRA] (WFWIP-207) UX: Force removal of Operator upon delete - do not hang due to finalizers
by Petr Kremensky (Jira)
Petr Kremensky created WFWIP-207:
------------------------------------
Summary: UX: Force removal of Operator upon delete - do not hang due to finalizers
Key: WFWIP-207
URL: https://issues.jboss.org/browse/WFWIP-207
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Petr Kremensky
Assignee: Brian Stansberry
We run yet into another use case where finalizers prevent users from deleting the project - the delete operation hangs.
pods:
{noformat}
$ oc get all
NAME READY STATUS RESTARTS AGE
pod/simple-jaxrs-operator-0 0/1 ImagePullBackOff 0 9m11s
pod/simple-jaxrs-operator-1 0/1 ImagePullBackOff 0 9m11s
pod/wildfly-operator-686846d6fb-db9sj 1/1 Running
$ oc delete wildflyserver simple-jaxrs-operator
wildflyserver.wildfly.org "simple-jaxrs-operator" deleted
... hangs forever
{noformat}
operator log:
{noformat}
{"level":"info","ts":1569308322.2926116,"logger":"controller_wildflyserver","msg":"Reconciling WildFlyServer","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator"}
{"level":"info","ts":1569308322.2927597,"logger":"controller_wildflyserver","msg":"WildflyServer is marked for deletion. Waiting for finalizers to clean the workspace","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator"}
{"level":"info","ts":1569308322.2929516,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator","Pod Name":"simple-jaxrs-operator-0","IP Address":"10.128.0.227","Pod State":"SCALING_DOWN_RECOVERY_INVESTIGATION","Pod Phase":"Pending"}
{"level":"info","ts":1569308322.2931426,"logger":"controller_wildflyserver","msg":"Transaction recovery scaledown processing","Request.Namespace":"pkremens-namespace","Request.Name":"simple-jaxrs-operator","Pod Name":"simple-jaxrs-operator-1","IP Address":"10.128.0.226","Pod State":"SCALING_DOWN_RECOVERY_INVESTIGATION","Pod Phase":"Pending"}
{"level":"error","ts":1569308322.294659,"logger":"kubebuilder.controller","msg":"Reconciler error","controller":"wildflyserver-controller","request":"pkremens-namespace/simple-jaxrs-operator","error":"Finalizer processing: failed transaction recovery for WildflyServer pkremens-namespace:simple-jaxrs-operator name Error: Found 2 errors:\n [[Pod 'simple-jaxrs-operator-0' / 'simple-jaxrs-operator' is in pending phase Pending. It will be hopefully started in a while. Transaction recovery needs the pod being fully started to be capable to mark it as clean for the scale down.]], [[Pod 'simple-jaxrs-operator-1' / 'simple-jaxrs-operator' is in pending phase Pending. It will be hopefully started in a while. Transaction recovery needs the pod being fully started to be capable to mark it as clean for the scale down.]],","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-l..."}
{noformat}
This is a call between safety vs. usability, but we believe that these issues (hanging delete command due to EAP7-1192) could be a serious usability problem for users.
*actual*
* scale down can require manual user interaction forced by finalizers
* delete can hang, requiring manual user interaction (delete deployment object, remove finalizer from operator CR, run delete again)
*expected*
* scale down can require manual user interaction forced by finalizers
* delete should never hang, it should be treated like a pulling a plug (rm -rf), in case users needs to make s graceful shutdown, he make a proper scale down to 0 prior the project deletion - this should be properly documented
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4560) executable-model wrongly calculates in eval with parenthesis
by Toshiya Kobayashi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4560?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-4560:
--------------------------------------
Git Pull Request: https://github.com/kiegroup/drools/pull/2551
> executable-model wrongly calculates in eval with parenthesis
> ------------------------------------------------------------
>
> Key: DROOLS-4560
> URL: https://issues.jboss.org/browse/DROOLS-4560
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.27.0.Final
> Environment: - executable-model
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> executable-model wrongly calculates in eval with parenthesis.
> For example, with this rule,
> {noformat}
> import org.drools.modelcompiler.domain.CalcFact;rule R when
> $p : CalcFact( $v1 : value1, $v2 : value2 )
> eval( ($v1 / ($v2 * 10) * 10) > 25 )
> then
> end
> {noformat}
> if $v1 = 1 and $v2 = 1, ($v1 / ($v2 * 10) * 10) is 1. So the rule should not fire.
> However, executable-model generates Java code:
> {code:java}
> public class Rules4A265EF484FEEE0E4E84E77B3DEB48F9RuleMethods0 {
> /**
> * Rule name: R
> */
> public static org.drools.model.Rule rule_R() {
> final org.drools.model.Variable<org.drools.modelcompiler.domain.CalcFact> var_$p = D.declarationOf(org.drools.modelcompiler.domain.CalcFact.class,
> "$p");
> final org.drools.model.Variable<Double> var_$v1 = D.declarationOf(Double.class,
> "$v1");
> final org.drools.model.Variable<Double> var_$v2 = D.declarationOf(Double.class,
> "$v2");
> org.drools.model.Rule rule = D.rule("R").build(D.bind(var_$v1).as(var_$p,
> (_this) -> _this.getValue1()).reactOn("value1"),
> D.bind(var_$v2).as(var_$p,
> (_this) -> _this.getValue2()).reactOn("value2"),
> D.expr("454A1C822808AC7491268E4F381F0EDA",
> var_$v1,
> var_$v2,
> ($v1, $v2) -> org.drools.modelcompiler.util.EvaluationUtil.greaterThanNumbers($v1 / $v2 * 10 * 10,
> 25d)),
> D.execute(() -> {
> }));
> return rule;
> }
> }
> {code}
> See that parentheses are removed so ($v1 / $v2 * 10 * 10) becomes 100.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4560) executable-model wrongly calculates in eval with parenthesis
by Toshiya Kobayashi (Jira)
[ https://issues.jboss.org/browse/DROOLS-4560?page=com.atlassian.jira.plugi... ]
Toshiya Kobayashi updated DROOLS-4560:
--------------------------------------
Description:
executable-model wrongly calculates in eval with parenthesis.
For example, with this rule,
{noformat}
import org.drools.modelcompiler.domain.CalcFact;rule R when
$p : CalcFact( $v1 : value1, $v2 : value2 )
eval( ($v1 / ($v2 * 10) * 10) > 25 )
then
end
{noformat}
if $v1 = 1 and $v2 = 1, ($v1 / ($v2 * 10) * 10) is 1. So the rule should not fire.
However, executable-model generates Java code:
{code:java}
public class Rules4A265EF484FEEE0E4E84E77B3DEB48F9RuleMethods0 {
/**
* Rule name: R
*/
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.CalcFact> var_$p = D.declarationOf(org.drools.modelcompiler.domain.CalcFact.class,
"$p");
final org.drools.model.Variable<Double> var_$v1 = D.declarationOf(Double.class,
"$v1");
final org.drools.model.Variable<Double> var_$v2 = D.declarationOf(Double.class,
"$v2");
org.drools.model.Rule rule = D.rule("R").build(D.bind(var_$v1).as(var_$p,
(_this) -> _this.getValue1()).reactOn("value1"),
D.bind(var_$v2).as(var_$p,
(_this) -> _this.getValue2()).reactOn("value2"),
D.expr("454A1C822808AC7491268E4F381F0EDA",
var_$v1,
var_$v2,
($v1, $v2) -> org.drools.modelcompiler.util.EvaluationUtil.greaterThanNumbers($v1 / $v2 * 10 * 10,
25d)),
D.execute(() -> {
}));
return rule;
}
}
{code}
See that parentheses are removed so ($v1 / $v2 * 10 * 10) becomes 100.
was:
executable-model wrongly calculates in eval with parenthesis.
For example, with this rule,
{noformat}
import org.drools.modelcompiler.domain.CalcFact;rule R when
$p : CalcFact( $v1 : value1, $v2 : value2 )
eval( ($v1 / ($v2 * 10) * 10) > 25 )
then
end
{noformat}
if $v1 = 1 and $v2 = 1, ($v1 / ($v2 * 10) * 10) is 1. So the rule should not fire.
However, executable-model generates Java code:
{code:java}
public class Rules4A265EF484FEEE0E4E84E77B3DEB48F9RuleMethods0 {
/**
* Rule name: R
*/
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.CalcFact> var_$p = D.declarationOf(org.drools.modelcompiler.domain.CalcFact.class,
"$p");
final org.drools.model.Variable<Double> var_$v1 = D.declarationOf(Double.class,
"$v1");
final org.drools.model.Variable<Double> var_$v2 = D.declarationOf(Double.class,
"$v2");
org.drools.model.Rule rule = D.rule("R").build(D.bind(var_$v1).as(var_$p,
(_this) -> _this.getValue1()).reactOn("value1"),
D.bind(var_$v2).as(var_$p,
(_this) -> _this.getValue2()).reactOn("value2"),
D.expr("454A1C822808AC7491268E4F381F0EDA",
var_$v1,
var_$v2,
($v1, $v2) -> org.drools.modelcompiler.util.EvaluationUtil.greaterThanNumbers($v1 / $v2 * 10 * 10,
25d)),
D.execute(() -> {
}));
return rule;
}
}
{code}
See that parentheses are removed so ($v1 / ($v2 * 10) * 10) becomes 100.
> executable-model wrongly calculates in eval with parenthesis
> ------------------------------------------------------------
>
> Key: DROOLS-4560
> URL: https://issues.jboss.org/browse/DROOLS-4560
> Project: Drools
> Issue Type: Bug
> Components: executable model
> Affects Versions: 7.27.0.Final
> Environment: - executable-model
> Reporter: Toshiya Kobayashi
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
>
> executable-model wrongly calculates in eval with parenthesis.
> For example, with this rule,
> {noformat}
> import org.drools.modelcompiler.domain.CalcFact;rule R when
> $p : CalcFact( $v1 : value1, $v2 : value2 )
> eval( ($v1 / ($v2 * 10) * 10) > 25 )
> then
> end
> {noformat}
> if $v1 = 1 and $v2 = 1, ($v1 / ($v2 * 10) * 10) is 1. So the rule should not fire.
> However, executable-model generates Java code:
> {code:java}
> public class Rules4A265EF484FEEE0E4E84E77B3DEB48F9RuleMethods0 {
> /**
> * Rule name: R
> */
> public static org.drools.model.Rule rule_R() {
> final org.drools.model.Variable<org.drools.modelcompiler.domain.CalcFact> var_$p = D.declarationOf(org.drools.modelcompiler.domain.CalcFact.class,
> "$p");
> final org.drools.model.Variable<Double> var_$v1 = D.declarationOf(Double.class,
> "$v1");
> final org.drools.model.Variable<Double> var_$v2 = D.declarationOf(Double.class,
> "$v2");
> org.drools.model.Rule rule = D.rule("R").build(D.bind(var_$v1).as(var_$p,
> (_this) -> _this.getValue1()).reactOn("value1"),
> D.bind(var_$v2).as(var_$p,
> (_this) -> _this.getValue2()).reactOn("value2"),
> D.expr("454A1C822808AC7491268E4F381F0EDA",
> var_$v1,
> var_$v2,
> ($v1, $v2) -> org.drools.modelcompiler.util.EvaluationUtil.greaterThanNumbers($v1 / $v2 * 10 * 10,
> 25d)),
> D.execute(() -> {
> }));
> return rule;
> }
> }
> {code}
> See that parentheses are removed so ($v1 / $v2 * 10 * 10) becomes 100.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (DROOLS-4560) executable-model wrongly calculates in eval with parenthesis
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-4560:
-----------------------------------------
Summary: executable-model wrongly calculates in eval with parenthesis
Key: DROOLS-4560
URL: https://issues.jboss.org/browse/DROOLS-4560
Project: Drools
Issue Type: Bug
Components: executable model
Affects Versions: 7.27.0.Final
Environment: - executable-model
Reporter: Toshiya Kobayashi
Assignee: Luca Molteni
executable-model wrongly calculates in eval with parenthesis.
For example, with this rule,
{noformat}
import org.drools.modelcompiler.domain.CalcFact;rule R when
$p : CalcFact( $v1 : value1, $v2 : value2 )
eval( ($v1 / ($v2 * 10) * 10) > 25 )
then
end
{noformat}
if $v1 = 1 and $v2 = 1, ($v1 / ($v2 * 10) * 10) is 1. So the rule should not fire.
However, executable-model generates Java code:
{code:java}
public class Rules4A265EF484FEEE0E4E84E77B3DEB48F9RuleMethods0 {
/**
* Rule name: R
*/
public static org.drools.model.Rule rule_R() {
final org.drools.model.Variable<org.drools.modelcompiler.domain.CalcFact> var_$p = D.declarationOf(org.drools.modelcompiler.domain.CalcFact.class,
"$p");
final org.drools.model.Variable<Double> var_$v1 = D.declarationOf(Double.class,
"$v1");
final org.drools.model.Variable<Double> var_$v2 = D.declarationOf(Double.class,
"$v2");
org.drools.model.Rule rule = D.rule("R").build(D.bind(var_$v1).as(var_$p,
(_this) -> _this.getValue1()).reactOn("value1"),
D.bind(var_$v2).as(var_$p,
(_this) -> _this.getValue2()).reactOn("value2"),
D.expr("454A1C822808AC7491268E4F381F0EDA",
var_$v1,
var_$v2,
($v1, $v2) -> org.drools.modelcompiler.util.EvaluationUtil.greaterThanNumbers($v1 / $v2 * 10 * 10,
25d)),
D.execute(() -> {
}));
return rule;
}
}
{code}
See that parentheses are removed so ($v1 / ($v2 * 10) * 10) becomes 100.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12582) ConcurrentModificationException in SharedObjectCache.getSharedSet
by Severian Duchenko (Jira)
[ https://issues.jboss.org/browse/WFLY-12582?page=com.atlassian.jira.plugin... ]
Severian Duchenko commented on WFLY-12582:
------------------------------------------
Hello [~manovotn]
No, I have not. Currently my company stick to 10.1.0.
It is very rare case, we have faced this issue only once.
And I guess it is very hard to reproduce this issue even on 10.1.0.
> ConcurrentModificationException in SharedObjectCache.getSharedSet
> -----------------------------------------------------------------
>
> Key: WFLY-12582
> URL: https://issues.jboss.org/browse/WFLY-12582
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: JBoss Admin Command-line Interface
> JBOSS_HOME: /home/user/wildfly-10.1.0.Final
> JBoss AS release: 2.2.0.Final "Kenny"
> JBoss AS product: WildFly Full 10.1.0.Final
> JAVA_HOME: /home/user/.sdkman/candidates/java/current
> java.version: 1.8.0_222
> java.vm.vendor: AdoptOpenJDK
> java.vm.version: 25.222-b10
> os.name: Linux
> os.version: 5.0.0-27-generic
> Reporter: Severian Duchenko
> Assignee: Matěj Novotný
> Priority: Minor
>
> Following error occurred during wildfly startup:
> {code}
> jboss.deployment.unit."MY.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) [rt.jar:1.8.0_202]
> at java.util.ArrayList$Itr.next(ArrayList.java:859) [rt.jar:1.8.0_202]
> at java.util.AbstractCollection.containsAll(AbstractCollection.java:317) [rt.jar:1.8.0_202]
> at java.util.AbstractSet.equals(AbstractSet.java:95) [rt.jar:1.8.0_202]
> at com.google.common.base.Equivalence$Equals.doEquivalent(Equivalence.java:327)
> at com.google.common.base.Equivalence.equivalent(Equivalence.java:71)
> at com.google.common.cache.LocalCache$Segment.getEntry(LocalCache.java:2711)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2180)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
> at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
> at org.jboss.weld.resources.SharedObjectCache.getSharedSet(SharedObjectCache.java:72)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.<init>(InferringFieldInjectionPointAttributes.java:47)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.of(InferringFieldInjectionPointAttributes.java:41)
> at org.jboss.weld.injection.InjectionPointFactory.createFieldInjectionPoint(InjectionPointFactory.java:140)
> at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:190)
> at org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
> at org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
> at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
> at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:113)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:86)
> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
> at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
> at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:229)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12582) ConcurrentModificationException in SharedObjectCache.getSharedSet
by Matěj Novotný (Jira)
[ https://issues.jboss.org/browse/WFLY-12582?page=com.atlassian.jira.plugin... ]
Matěj Novotný commented on WFLY-12582:
--------------------------------------
Hello [~sduchenko]
WFLY 10 is a very ancient version which runs even more ancient version of Weld (that isn't actively developed anymore) - actually with CDI 1.2 impl whereas now we are running 2.0 impl.
Would you care to try with some of the recent releases?
> ConcurrentModificationException in SharedObjectCache.getSharedSet
> -----------------------------------------------------------------
>
> Key: WFLY-12582
> URL: https://issues.jboss.org/browse/WFLY-12582
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: JBoss Admin Command-line Interface
> JBOSS_HOME: /home/user/wildfly-10.1.0.Final
> JBoss AS release: 2.2.0.Final "Kenny"
> JBoss AS product: WildFly Full 10.1.0.Final
> JAVA_HOME: /home/user/.sdkman/candidates/java/current
> java.version: 1.8.0_222
> java.vm.vendor: AdoptOpenJDK
> java.vm.version: 25.222-b10
> os.name: Linux
> os.version: 5.0.0-27-generic
> Reporter: Severian Duchenko
> Assignee: Matěj Novotný
> Priority: Minor
>
> Following error occurred during wildfly startup:
> {code}
> jboss.deployment.unit."MY.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) [rt.jar:1.8.0_202]
> at java.util.ArrayList$Itr.next(ArrayList.java:859) [rt.jar:1.8.0_202]
> at java.util.AbstractCollection.containsAll(AbstractCollection.java:317) [rt.jar:1.8.0_202]
> at java.util.AbstractSet.equals(AbstractSet.java:95) [rt.jar:1.8.0_202]
> at com.google.common.base.Equivalence$Equals.doEquivalent(Equivalence.java:327)
> at com.google.common.base.Equivalence.equivalent(Equivalence.java:71)
> at com.google.common.cache.LocalCache$Segment.getEntry(LocalCache.java:2711)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2180)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
> at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
> at org.jboss.weld.resources.SharedObjectCache.getSharedSet(SharedObjectCache.java:72)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.<init>(InferringFieldInjectionPointAttributes.java:47)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.of(InferringFieldInjectionPointAttributes.java:41)
> at org.jboss.weld.injection.InjectionPointFactory.createFieldInjectionPoint(InjectionPointFactory.java:140)
> at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:190)
> at org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
> at org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
> at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
> at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:113)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:86)
> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
> at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
> at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:229)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12582) ConcurrentModificationException in SharedObjectCache.getSharedSet
by Severian Duchenko (Jira)
[ https://issues.jboss.org/browse/WFLY-12582?page=com.atlassian.jira.plugin... ]
Severian Duchenko commented on WFLY-12582:
------------------------------------------
Looks like root cause is concurrent modification of key used for caching during cache value calculation.
Race condition of methods ArraySet.equals and ArraySet.trimToSize .
{code}
package org.jboss.weld.resources;
...
public class SharedObjectCache implements BootstrapService {
....
private final LoadingCache<Set<?>, Set<?>> sharedSets = CacheBuilder.newBuilder().build(new CacheLoader<Set<?>, Set<?>>() {
@Override
public Set<?> load(Set<?> from) {
return WeldCollections.immutableSet(from); // <-- HERE
}
});
...
package org.jboss.weld.util.collections;
...
public class WeldCollections {
...
public static <T> Set<T> immutableSet(Set<T> set) {
if (set.isEmpty()) {
return Collections.emptySet();
}
if (set instanceof ImmutableSet<?>) {
return set;
}
if (set instanceof ArraySet<?>) {
ArraySet.class.cast(set).trimToSize(); // <-- HERE
}
return Collections.unmodifiableSet(set);
}
{code}
> ConcurrentModificationException in SharedObjectCache.getSharedSet
> -----------------------------------------------------------------
>
> Key: WFLY-12582
> URL: https://issues.jboss.org/browse/WFLY-12582
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: JBoss Admin Command-line Interface
> JBOSS_HOME: /home/user/wildfly-10.1.0.Final
> JBoss AS release: 2.2.0.Final "Kenny"
> JBoss AS product: WildFly Full 10.1.0.Final
> JAVA_HOME: /home/user/.sdkman/candidates/java/current
> java.version: 1.8.0_222
> java.vm.vendor: AdoptOpenJDK
> java.vm.version: 25.222-b10
> os.name: Linux
> os.version: 5.0.0-27-generic
> Reporter: Severian Duchenko
> Assignee: Matěj Novotný
> Priority: Minor
>
> Following error occurred during wildfly startup:
> {code}
> jboss.deployment.unit."MY.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) [rt.jar:1.8.0_202]
> at java.util.ArrayList$Itr.next(ArrayList.java:859) [rt.jar:1.8.0_202]
> at java.util.AbstractCollection.containsAll(AbstractCollection.java:317) [rt.jar:1.8.0_202]
> at java.util.AbstractSet.equals(AbstractSet.java:95) [rt.jar:1.8.0_202]
> at com.google.common.base.Equivalence$Equals.doEquivalent(Equivalence.java:327)
> at com.google.common.base.Equivalence.equivalent(Equivalence.java:71)
> at com.google.common.cache.LocalCache$Segment.getEntry(LocalCache.java:2711)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2180)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
> at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
> at org.jboss.weld.resources.SharedObjectCache.getSharedSet(SharedObjectCache.java:72)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.<init>(InferringFieldInjectionPointAttributes.java:47)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.of(InferringFieldInjectionPointAttributes.java:41)
> at org.jboss.weld.injection.InjectionPointFactory.createFieldInjectionPoint(InjectionPointFactory.java:140)
> at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:190)
> at org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
> at org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
> at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
> at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:113)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:86)
> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
> at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
> at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:229)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12582) ConcurrentModificationException in SharedObjectCache.getSharedSet
by Severian Duchenko (Jira)
[ https://issues.jboss.org/browse/WFLY-12582?page=com.atlassian.jira.plugin... ]
Severian Duchenko updated WFLY-12582:
-------------------------------------
Affects Version/s: 10.1.0.Final
> ConcurrentModificationException in SharedObjectCache.getSharedSet
> -----------------------------------------------------------------
>
> Key: WFLY-12582
> URL: https://issues.jboss.org/browse/WFLY-12582
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 10.1.0.Final
> Environment: JBoss Admin Command-line Interface
> JBOSS_HOME: /home/user/wildfly-10.1.0.Final
> JBoss AS release: 2.2.0.Final "Kenny"
> JBoss AS product: WildFly Full 10.1.0.Final
> JAVA_HOME: /home/user/.sdkman/candidates/java/current
> java.version: 1.8.0_222
> java.vm.vendor: AdoptOpenJDK
> java.vm.version: 25.222-b10
> os.name: Linux
> os.version: 5.0.0-27-generic
> Reporter: Severian Duchenko
> Assignee: Matěj Novotný
> Priority: Minor
>
> Following error occurred during wildfly startup:
> {code}
> jboss.deployment.unit."MY.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) [rt.jar:1.8.0_202]
> at java.util.ArrayList$Itr.next(ArrayList.java:859) [rt.jar:1.8.0_202]
> at java.util.AbstractCollection.containsAll(AbstractCollection.java:317) [rt.jar:1.8.0_202]
> at java.util.AbstractSet.equals(AbstractSet.java:95) [rt.jar:1.8.0_202]
> at com.google.common.base.Equivalence$Equals.doEquivalent(Equivalence.java:327)
> at com.google.common.base.Equivalence.equivalent(Equivalence.java:71)
> at com.google.common.cache.LocalCache$Segment.getEntry(LocalCache.java:2711)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2180)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
> at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
> at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
> at org.jboss.weld.resources.SharedObjectCache.getSharedSet(SharedObjectCache.java:72)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.<init>(InferringFieldInjectionPointAttributes.java:47)
> at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.of(InferringFieldInjectionPointAttributes.java:41)
> at org.jboss.weld.injection.InjectionPointFactory.createFieldInjectionPoint(InjectionPointFactory.java:140)
> at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:190)
> at org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
> at org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
> at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
> at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
> at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:113)
> at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:86)
> at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
> at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
> at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
> at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:229)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
> at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months
[JBoss JIRA] (WFLY-12582) ConcurrentModificationException in SharedObjectCache.getSharedSet
by Severian Duchenko (Jira)
Severian Duchenko created WFLY-12582:
----------------------------------------
Summary: ConcurrentModificationException in SharedObjectCache.getSharedSet
Key: WFLY-12582
URL: https://issues.jboss.org/browse/WFLY-12582
Project: WildFly
Issue Type: Bug
Components: CDI / Weld
Environment: JBoss Admin Command-line Interface
JBOSS_HOME: /home/user/wildfly-10.1.0.Final
JBoss AS release: 2.2.0.Final "Kenny"
JBoss AS product: WildFly Full 10.1.0.Final
JAVA_HOME: /home/user/.sdkman/candidates/java/current
java.version: 1.8.0_222
java.vm.vendor: AdoptOpenJDK
java.vm.version: 25.222-b10
os.name: Linux
os.version: 5.0.0-27-generic
Reporter: Severian Duchenko
Assignee: Matěj Novotný
Following error occurred during wildfly startup:
{code}
jboss.deployment.unit."MY.ear".WeldStartService: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:909) [rt.jar:1.8.0_202]
at java.util.ArrayList$Itr.next(ArrayList.java:859) [rt.jar:1.8.0_202]
at java.util.AbstractCollection.containsAll(AbstractCollection.java:317) [rt.jar:1.8.0_202]
at java.util.AbstractSet.equals(AbstractSet.java:95) [rt.jar:1.8.0_202]
at com.google.common.base.Equivalence$Equals.doEquivalent(Equivalence.java:327)
at com.google.common.base.Equivalence.equivalent(Equivalence.java:71)
at com.google.common.cache.LocalCache$Segment.getEntry(LocalCache.java:2711)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2180)
at com.google.common.cache.LocalCache.get(LocalCache.java:3937)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941)
at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
at org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
at org.jboss.weld.resources.SharedObjectCache.getSharedSet(SharedObjectCache.java:72)
at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.<init>(InferringFieldInjectionPointAttributes.java:47)
at org.jboss.weld.injection.attributes.InferringFieldInjectionPointAttributes.of(InferringFieldInjectionPointAttributes.java:41)
at org.jboss.weld.injection.InjectionPointFactory.createFieldInjectionPoint(InjectionPointFactory.java:140)
at org.jboss.weld.injection.ResourceInjectionFactory$ResourceInjectionProcessor.createResourceInjections(ResourceInjectionFactory.java:190)
at org.jboss.weld.injection.ResourceInjectionFactory.discoverType(ResourceInjectionFactory.java:449)
at org.jboss.weld.injection.ResourceInjectionFactory.getResourceInjections(ResourceInjectionFactory.java:97)
at org.jboss.weld.injection.producer.ResourceInjector.<init>(ResourceInjector.java:59)
at org.jboss.weld.injection.producer.ResourceInjector.of(ResourceInjector.java:49)
at org.jboss.weld.injection.producer.BeanInjectionTarget.<init>(BeanInjectionTarget.java:63)
at org.jboss.weld.injection.producer.BeanInjectionTarget.createDefault(BeanInjectionTarget.java:47)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:113)
at org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:86)
at org.jboss.weld.bean.ManagedBean.<init>(ManagedBean.java:100)
at org.jboss.weld.bean.ManagedBean.of(ManagedBean.java:80)
at org.jboss.weld.bootstrap.AbstractBeanDeployer.createManagedBean(AbstractBeanDeployer.java:261)
at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:229)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:78)
at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$2.doWork(ConcurrentBeanDeployer.java:75)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_202]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_202]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_202]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_202]
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 10 months