[JBoss JIRA] (DROOLS-2668) Drools persistence tests fail on DB2 after changing Tx sync registration to not interposed.
by Radovan Synek (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2668?page=com.atlassian.jira.plugi... ]
Radovan Synek updated DROOLS-2668:
----------------------------------
Summary: Drools persistence tests fail on DB2 after changing Tx sync registration to not interposed. (was: Drools persistance tests fail on DB2 after changing Tx sync registration to not interposed.)
> Drools persistence tests fail on DB2 after changing Tx sync registration to not interposed.
> -------------------------------------------------------------------------------------------
>
> Key: DROOLS-2668
> URL: https://issues.jboss.org/browse/DROOLS-2668
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Radovan Synek
> Assignee: Mario Fusco
>
> After incorporating changes proposed in https://issues.jboss.org/browse/JBPM-7347, tests in drools-persistence module started failing with DB2-10.5 due to:
> ARJUNA016129: Could not end XA resource com.ibm.db2.jcc.t4.ec@66f4fb48
> com.ibm.db2.jcc.am.XaException: [jcc][t4][10401][12066][4.19.26] XA exception: XA_RBROLLBACK ERRORCODE=-4228, SQLSTATE=null
> On every other DB all the tests passed.
> Please note that the issue is not present on any branch yet; this is a result of testing before the aforementioned changes are merged.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak commented on JGRP-2227:
-------------------------------------
I retested it with Infinispan 9.3.0Final, which contains jgroups 4.0.12, however I can still reproduce the issue.
I have 2 nodes which I am trying to connect to one Infinispan cluster. When I am joining 2nd node, when I start Infinispan cache, I see that jgroups communication channels are starting. Also I see that authenticate() method in my Token implementation is triggered. In authenticate() method I only return false to simulate authentication failure.
After method authenticate() return false, I see in logs
2018-06-27 21:34:52,092 WARN [jgroups-128,tra_commandsChannel,809272a0-d1b7-4e82-a8a7-98ae321c88cf-d2d68] (Log4J2LogImpl.java:96) - 809272a0-d1b7-4e82-a8a7-98ae321c88cf-d2d68: failed to validate AuthHeader (token: InfinityCommandsAuthToken) from c1a2e420-1384-4a1d-8dbd-de19127b1d86-8994a; dropping message and sending rejection message
However, I did not catch any SecurityException in my code. Also in my Intellij IDEA I have breakpoint set for any SecurityException, however nothing is thrown.
In attachment I include my jgroups configuration, my Token implementation and as well jgroups logs.
[^jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip]
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (DROOLS-2668) Drools persistance tests fail on DB2 after changing Tx sync registration to not interposed.
by Radovan Synek (JIRA)
Radovan Synek created DROOLS-2668:
-------------------------------------
Summary: Drools persistance tests fail on DB2 after changing Tx sync registration to not interposed.
Key: DROOLS-2668
URL: https://issues.jboss.org/browse/DROOLS-2668
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Radovan Synek
Assignee: Mario Fusco
After incorporating changes proposed in https://issues.jboss.org/browse/JBPM-7347, tests in drools-persistence module started failing with DB2-10.5 due to:
ARJUNA016129: Could not end XA resource com.ibm.db2.jcc.t4.ec@66f4fb48
com.ibm.db2.jcc.am.XaException: [jcc][t4][10401][12066][4.19.26] XA exception: XA_RBROLLBACK ERRORCODE=-4228, SQLSTATE=null
On every other DB all the tests passed.
Please note that the issue is not present on any branch yet; this is a result of testing before the aforementioned changes are merged.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (JGRP-2227) Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
by Robert Cernak (JIRA)
[ https://issues.jboss.org/browse/JGRP-2227?page=com.atlassian.jira.plugin.... ]
Robert Cernak updated JGRP-2227:
--------------------------------
Attachment: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip
> Use of AUTH does not result in a SecurityException, but instead nodes create separate clusters with the same name
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2227
> URL: https://issues.jboss.org/browse/JGRP-2227
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.6
> Reporter: Robert Cernak
> Assignee: Bela Ban
> Fix For: 4.0.12
>
> Attachments: jgroupsDoesNotThrowSecurityExceptionWithJgroups4012.zip, jgroupsLogs.zip
>
>
> I implemented method org.jgroups.auth.AuthToken#authenticate(AuthToken token, Message msg) in my class and its body contained only one line: return false;
> In this way authentication should be false and I should get SecurityException.
> When I started joining of nodes together to form a cluster, instead of getting SecurityException, nodes formed 2 different clusters with the same name.
> I am sure method was evaluated, since I tried to run it also with breakpoint, which was triggered during joining process.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFLY-6405) Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-6405?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-6405:
----------------------------------
[~jan.swaelens] Looking at the dates of the commits, it would definitely be fixed in EAP 7.1.x.
> Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
> ---------------------------------------------------------------------------
>
> Key: WFLY-6405
> URL: https://issues.jboss.org/browse/WFLY-6405
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading
> Affects Versions: 10.0.0.Final
> Reporter: Panos Grigoropoulos
> Assignee: Stuart Douglas
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
>
> (Wildfly 10.0.0.FINAL)
> During the performance test of my app (50 concurrent users with jmeter) I am running into the following issue:
> There are locked threads in the method WeldDeployment.getBeanDeploymentArchive(). Looking the code, this method is synchronized, so it makes sense. The question is, is this the expected behavior or this is a bug. In both cases is there any workaround to overcome this limitation?
> STACK TRACE:
> ....
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():73
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():93
> org.jboss.as.weld.deployment.WeldDeployment.getBeanDeploymentArchive():226
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFLY-10655) SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-10655?page=com.atlassian.jira.plugin... ]
Martin Kouba commented on WFLY-10655:
-------------------------------------
I don't think this is a Weld subsytem issue. In any case, the fix for WFLY-1946 was reverted in https://github.com/wildfly/wildfly/commit/89b5a0f42e59c012e7f11f7fb6ba593....
> SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
> -------------------------------------------------------------------------------
>
> Key: WFLY-10655
> URL: https://issues.jboss.org/browse/WFLY-10655
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 13.0.0.Final
> Reporter: tommaso borgato
> Assignee: Martin Kouba
>
> Affected scenario is eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync.
> Every time the server is stated or re-started, we observed the following SEVERE logs just after clusterbench is deployed (clusterbench is an ear that uses JSF); we observed them systematically on each of the 4 nodes composing the cluster:
> {noformat}
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 72) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-granular.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started client-mappings cache from ejb container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 73) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0002: Started default-server cache from web container
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 76) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> 2018-06-27 02:47:07,578 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> 2018-06-27 02:47:07,673 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.jberet.creation.BatchBeanProducer is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,713 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,739 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class com.sun.faces.flow.FlowDiscoveryCDIHelper is deprecated from CDI 1.1!
> 2018-06-27 02:47:08,149 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,163 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 76) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-granular'
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 72) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench'
> 2018-06-27 02:47:08,587 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-passivating'
> 2018-06-27 02:47:09,860 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/clusterbench-granular' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 72) WFLYUT0021: Registered web context: '/clusterbench' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/clusterbench-passivating' for server 'default-server'
> 2018-06-27 02:47:09,889 INFO [org.jboss.as.server] (ServerService Thread Pool -- 42) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 2018-06-27 02:47:09,989 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> {noformat}
>
> Complete log [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap...]
> Already observed a very long time ago: https://issues.jboss.org/browse/WFLY-1946
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFLY-10655) SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-10655?page=com.atlassian.jira.plugin... ]
Martin Kouba reassigned WFLY-10655:
-----------------------------------
Assignee: Farah Juma (was: Martin Kouba)
> SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
> -------------------------------------------------------------------------------
>
> Key: WFLY-10655
> URL: https://issues.jboss.org/browse/WFLY-10655
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 13.0.0.Final
> Reporter: tommaso borgato
> Assignee: Farah Juma
>
> Affected scenario is eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync.
> Every time the server is stated or re-started, we observed the following SEVERE logs just after clusterbench is deployed (clusterbench is an ear that uses JSF); we observed them systematically on each of the 4 nodes composing the cluster:
> {noformat}
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 72) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-granular.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started client-mappings cache from ejb container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 73) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0002: Started default-server cache from web container
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 76) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> 2018-06-27 02:47:07,578 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> 2018-06-27 02:47:07,673 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.jberet.creation.BatchBeanProducer is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,713 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,739 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class com.sun.faces.flow.FlowDiscoveryCDIHelper is deprecated from CDI 1.1!
> 2018-06-27 02:47:08,149 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,163 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 76) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-granular'
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 72) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench'
> 2018-06-27 02:47:08,587 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-passivating'
> 2018-06-27 02:47:09,860 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/clusterbench-granular' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 72) WFLYUT0021: Registered web context: '/clusterbench' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/clusterbench-passivating' for server 'default-server'
> 2018-06-27 02:47:09,889 INFO [org.jboss.as.server] (ServerService Thread Pool -- 42) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 2018-06-27 02:47:09,989 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> {noformat}
>
> Complete log [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap...]
> Already observed a very long time ago: https://issues.jboss.org/browse/WFLY-1946
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (JGRP-2276) MERGE3: a dead member as merge leader will never trigger a merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2276?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2276 at 6/29/18 3:47 AM:
---------------------------------------------------------
For the moment, when a coord leaves and a member drops the view message and doesn't install it, MERGE3 will handle this and make every member agree on the view.
I might open another JIRA to handle this scenario of a graceful coord-leave later...
JIRA is JGRP-2277
was (Author: belaban):
For the moment, when a coord leaves and a member drops the view message and doesn't install it, MERGE3 will handle this and make every member agree on the view.
I might open another JIRA to handle this scenario of a graceful coord-leave later...
> MERGE3: a dead member as merge leader will never trigger a merge
> ----------------------------------------------------------------
>
> Key: JGRP-2276
> URL: https://issues.jboss.org/browse/JGRP-2276
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.12
>
>
> When we have member(s) which have a view with a dead member as coordinator, when the dead member becomes part of the subgroup coordinators and _happens to be chosen as merge leader_, then a merge will never ensue.
> Example:
> * Member 2 (with view 2|5) was the previous coordinator and left the cluster, installing view 3|6 before stopping
> ** View 2|5=\{2,3,4,5,6,7\}; view 3|6=\{3,4,5,6,7\}
> * Member 7 didn't get view 3|6 and still has view 2|5
> * Everybody else has view 3|6
> * MERGE3 gets the following views:
> ** 2|5: 7 // member 7 has this view
> ** 3|6: 3,4,5,6 // members 3,4,5 and 6 have this view
> * 2 and 3 are added to a _sorted set_ and the first member of the set (2) is chose as merge leader. 3 doesn't take any action, as it notices it won't be the merge leader
> ** The reason 2 was first in the sorted set is that (possibly by coincidence) its UUID is *lower* than that of 3. If this wasn't the case, 3 would be merge leader and start (and successfully complete) a merge. However, with dead member 2 being picked as merge leader, a merge will never be triggered!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months
[JBoss JIRA] (WFLY-10655) SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-10655?page=com.atlassian.jira.plugin... ]
Martin Kouba updated WFLY-10655:
--------------------------------
Affects Version/s: 13.0.0.Final
> SEVERE error on deploy of ear: "Unable to obtain CDI 1.1 utilities for Mojarra"
> -------------------------------------------------------------------------------
>
> Key: WFLY-10655
> URL: https://issues.jboss.org/browse/WFLY-10655
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JSF
> Affects Versions: 13.0.0.Final
> Reporter: tommaso borgato
> Assignee: Martin Kouba
>
> Affected scenario is eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync.
> Every time the server is stated or re-started, we observed the following SEVERE logs just after clusterbench is deployed (clusterbench is an ear that uses JSF); we observed them systematically on each of the 4 nodes composing the cluster:
> {noformat}
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 72) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-granular.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started client-mappings cache from ejb container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 73) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-default.war cache from web container
> 2018-06-27 02:47:07,440 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 74) WFLYCLINF0002: Started default-server cache from web container
> 2018-06-27 02:47:07,439 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 76) WFLYCLINF0002: Started clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> 2018-06-27 02:47:07,578 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 75) WFLYCLINF0002: Started clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> 2018-06-27 02:47:07,673 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.jberet.creation.BatchBeanProducer is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,713 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class org.hibernate.validator.internal.cdi.interceptor.ValidationInterceptor is deprecated from CDI 1.1!
> 2018-06-27 02:47:07,739 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-7) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class com.sun.faces.flow.FlowDiscoveryCDIHelper is deprecated from CDI 1.1!
> 2018-06-27 02:47:08,149 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,163 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view] (MSC service thread 1-7) Unable to obtain CDI 1.1 utilities for Mojarra
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 76) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-granular'
> 2018-06-27 02:47:08,586 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 72) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench'
> 2018-06-27 02:47:08,587 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 78) Initializing Mojarra 2.2.13.SP5 for context '/clusterbench-passivating'
> 2018-06-27 02:47:09,860 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 76) WFLYUT0021: Registered web context: '/clusterbench-granular' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 72) WFLYUT0021: Registered web context: '/clusterbench' for server 'default-server'
> 2018-06-27 02:47:09,863 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 78) WFLYUT0021: Registered web context: '/clusterbench-passivating' for server 'default-server'
> 2018-06-27 02:47:09,889 INFO [org.jboss.as.server] (ServerService Thread Pool -- 42) WFLYSRV0010: Deployed "clusterbench-ee7.ear" (runtime-name : "clusterbench-ee7.ear")
> 2018-06-27 02:47:09,989 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> {noformat}
>
> Complete log [here|https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap...]
> Already observed a very long time ago: https://issues.jboss.org/browse/WFLY-1946
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 3 months