[JBoss JIRA] (WFLY-12391) Test BridgeFromJTATestCase is not run by default
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFLY-12391:
---------------------------------------
Summary: Test BridgeFromJTATestCase is not run by default
Key: WFLY-12391
URL: https://issues.jboss.org/browse/WFLY-12391
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 17.0.1.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
The jta txbridge test `org.jboss.as.test.txbridge.fromjta.BridgeFromJTATestCase` is not enabled to be run by default when `integration/xts` tests are run.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFLY-12390) Hot-Deploy throws IllegalStateException: Timer already cancelled
by David Schmidt (Jira)
David Schmidt created WFLY-12390:
------------------------------------
Summary: Hot-Deploy throws IllegalStateException: Timer already cancelled
Key: WFLY-12390
URL: https://issues.jboss.org/browse/WFLY-12390
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 17.0.1.Final
Environment: any OS
single Wildfly 17 (not yet in production)
Reporter: David Schmidt
Assignee: Brian Stansberry
I did an Upgrade from 11 to 17.0.1 and now I'm getting IllegalStateException on hot-deploys.
What I tried without result:
* truncate the jboss_ejb_timer table (to remove existing)
* remove all old @Schedule and add a new different timer
* use @Resource TimerService instead of @Schedule
restart allows to deploy again (for a time)
{code}
2019-08-16 16:13:14,940 ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."xxxxxxx.war".component.CronJobs.START: org.jboss.msc.service.Star
tException in service jboss.deployment.unit."xxxxxxx.war".component.CronJobs.START: java.lang.IllegalStateException: Timer already cancelled.
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.lang.IllegalStateException: Timer already cancelled.
at java.util.Timer.sched(Timer.java:397)
at java.util.Timer.schedule(Timer.java:193)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.scheduleTimeout(TimerServiceImpl.java:906)
at org.jboss.as.ejb3.timerservice.TimerImpl.scheduleTimeout(TimerImpl.java:537)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.startTimer(TimerServiceImpl.java:785)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:756)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
at org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
at org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:136)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
... 8 more
{code}
As it happens in programming, I can't reproduce this at the moment. I got tormented for weeks but today it doesn't happen...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (JGRP-2369) Remove message indicating that UFC is not needed when using a TCP transport
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2369?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2369:
--------------------------------
This warning message _has_ been removed (I'd have to check in which version though...).
By default, UFC has been added back to the TCP-based stacks.
> Remove message indicating that UFC is not needed when using a TCP transport
> ----------------------------------------------------------------------------
>
> Key: JGRP-2369
> URL: https://issues.jboss.org/browse/JGRP-2369
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.11
> Environment: Red Hat JBoss Data Grid
> * 7.2 (which uses JGroups 4.0.11)
> Reporter: Jonathan Mason
> Assignee: Bela Ban
> Priority: Minor
>
> By default, protocol UFC is removed from the default TCP stack (in JDG). However, depending on the type of cache replication used (i.e., ASYNC), the UFC protocol may be of some benefit. Adding the UFC protocol into the TCP stack results in a message [1] indicating that it is not needed. This message should be removed.
> [1]
> INFO [org.jgroups.protocols.UFC] (MSC service thread 1-7) UFC is not needed (and can be removed) as we're running on a TCP transport
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-176) Pod restarted because of failing liveness/rediness Probe
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-176?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFWIP-176:
-------------------------------
Description:
During testing 73 image I came to case where really corner case is tested [0].
Test is not using templates for deployment.
In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however, there was no liveness/rediness failures in events. Pod was not restarted.
I dont see differences in pod yaml for CD16 case
{code}
livenessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/livenessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: weirdusername
readinessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/readinessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
{code}
and CD 17 case
{code}
livenessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/livenessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: weirdusername
readinessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/readinessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
{code}
What could change this behaviour change?
[0] https://issues.jboss.org/browse/CLOUD-1988
was:
During testing 73 image I came to case where really corner case is tested [0].
I believe the recent change about probes timeouts [1] change the behaviour little bit. And I wnat to make sure it is expected.
In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however pod was not restarted. Is this expected?
Is this scenario real?: User didnt care so far about liveness/readiness probes - they were failing. Application is working. After migrating to CD17/EAP73 image pod will be restarting and application will be down.
[0] https://issues.jboss.org/browse/CLOUD-1988
[1] https://issues.jboss.org/browse/CLOUD-3248
> Pod restarted because of failing liveness/rediness Probe
> --------------------------------------------------------
>
> Key: WFWIP-176
> URL: https://issues.jboss.org/browse/WFWIP-176
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Ken Wills
> Priority: Major
>
> During testing 73 image I came to case where really corner case is tested [0].
> Test is not using templates for deployment.
> In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however, there was no liveness/rediness failures in events. Pod was not restarted.
> I dont see differences in pod yaml for CD16 case
> {code}
> livenessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/livenessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> name: weirdusername
> readinessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/readinessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> {code}
> and CD 17 case
> {code}
> livenessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/livenessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> name: weirdusername
> readinessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/readinessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> {code}
> What could change this behaviour change?
> [0] https://issues.jboss.org/browse/CLOUD-1988
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-176) Pod restarted because of failing liveness/rediness Probe
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-176?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFWIP-176:
-------------------------------
Description:
During testing 73 image I came to case where really corner case is tested [0].
Test is not using templates for deployment.
In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however, there was no liveness/rediness failures in events. Pod was not restarted.
I dont see differences in pod yaml for CD16 case
{code}
livenessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/livenessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: weirdusername
readinessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/readinessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
{code}
and CD 17 case
{code}
livenessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/livenessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: weirdusername
readinessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/readinessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
{code}
What could cause this behaviour change?
[0] https://issues.jboss.org/browse/CLOUD-1988
was:
During testing 73 image I came to case where really corner case is tested [0].
Test is not using templates for deployment.
In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however, there was no liveness/rediness failures in events. Pod was not restarted.
I dont see differences in pod yaml for CD16 case
{code}
livenessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/livenessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: weirdusername
readinessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/readinessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
{code}
and CD 17 case
{code}
livenessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/livenessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: weirdusername
readinessProbe:
exec:
command:
- /bin/bash
- '-c'
- /opt/eap/bin/readinessProbe.sh
failureThreshold: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
{code}
What could change this behaviour change?
[0] https://issues.jboss.org/browse/CLOUD-1988
> Pod restarted because of failing liveness/rediness Probe
> --------------------------------------------------------
>
> Key: WFWIP-176
> URL: https://issues.jboss.org/browse/WFWIP-176
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Ken Wills
> Priority: Major
>
> During testing 73 image I came to case where really corner case is tested [0].
> Test is not using templates for deployment.
> In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however, there was no liveness/rediness failures in events. Pod was not restarted.
> I dont see differences in pod yaml for CD16 case
> {code}
> livenessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/livenessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> name: weirdusername
> readinessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/readinessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> {code}
> and CD 17 case
> {code}
> livenessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/livenessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> name: weirdusername
> readinessProbe:
> exec:
> command:
> - /bin/bash
> - '-c'
> - /opt/eap/bin/readinessProbe.sh
> failureThreshold: 3
> periodSeconds: 10
> successThreshold: 1
> timeoutSeconds: 1
> {code}
> What could cause this behaviour change?
> [0] https://issues.jboss.org/browse/CLOUD-1988
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-176) Pod restarted because of failing liveness/rediness Probe
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-176?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFWIP-176:
-------------------------------
Summary: Pod restarted because of failing liveness/rediness Probe (was: Pod restarted because of failing readinessProbe)
> Pod restarted because of failing liveness/rediness Probe
> --------------------------------------------------------
>
> Key: WFWIP-176
> URL: https://issues.jboss.org/browse/WFWIP-176
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Ken Wills
> Priority: Major
>
> During testing 73 image I came to case where really corner case is tested [0].
> I believe the recent change about probes timeouts [1] change the behaviour little bit. And I wnat to make sure it is expected.
> In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however pod was not restarted. Is this expected?
> Is this scenario real?: User didnt care so far about liveness/readiness probes - they were failing. Application is working. After migrating to CD17/EAP73 image pod will be restarting and application will be down.
> [0] https://issues.jboss.org/browse/CLOUD-1988
> [1] https://issues.jboss.org/browse/CLOUD-3248
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-176) Pod restarted because of failing readinessProbe
by Martin Choma (Jira)
[ https://issues.jboss.org/browse/WFWIP-176?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFWIP-176:
-------------------------------
Description:
During testing 73 image I came to case where really corner case is tested [0].
I believe the recent change about probes timeouts [1] change the behaviour little bit. And I wnat to make sure it is expected.
In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however pod was not restarted. Is this expected?
Is this scenario real?: User didnt care so far about liveness/readiness probes - they were failing. Application is working. After migrating to CD17/EAP73 image pod will be restarting and application will be down.
[0] https://issues.jboss.org/browse/CLOUD-1988
[1] https://issues.jboss.org/browse/CLOUD-3248
was:
During testing 73 image I came to case where really corner case is tested [0].
I believe the recent change about probes timeouts [1] change the behaviour little bit. And I wnat to make sure it is expected.
In tested scenario readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however pod was not restarted. Is this expected?
Is this scenario real?: User didnt care so far about readiness probes - they were failing. Application is working. After migrating to CD17/EAP73 image pod will be restarting and application will be down.
[0] https://issues.jboss.org/browse/CLOUD-1988
[1] https://issues.jboss.org/browse/CLOUD-3248
> Pod restarted because of failing readinessProbe
> -----------------------------------------------
>
> Key: WFWIP-176
> URL: https://issues.jboss.org/browse/WFWIP-176
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Ken Wills
> Priority: Major
>
> During testing 73 image I came to case where really corner case is tested [0].
> I believe the recent change about probes timeouts [1] change the behaviour little bit. And I wnat to make sure it is expected.
> In tested scenario liveness/readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however pod was not restarted. Is this expected?
> Is this scenario real?: User didnt care so far about liveness/readiness probes - they were failing. Application is working. After migrating to CD17/EAP73 image pod will be restarting and application will be down.
> [0] https://issues.jboss.org/browse/CLOUD-1988
> [1] https://issues.jboss.org/browse/CLOUD-3248
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (WFWIP-176) Pod restarted because of failing readinessProbe
by Martin Choma (Jira)
Martin Choma created WFWIP-176:
----------------------------------
Summary: Pod restarted because of failing readinessProbe
Key: WFWIP-176
URL: https://issues.jboss.org/browse/WFWIP-176
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Martin Choma
Assignee: Brian Stansberry
During testing 73 image I came to case where really corner case is tested [0].
I believe the recent change about probes timeouts [1] change the behaviour little bit. And I wnat to make sure it is expected.
In tested scenario readiness probe fails. In CD 17 and eap 73 pod is restarted. In CD 16 however pod was not restarted. Is this expected?
Is this scenario real?: User didnt care so far about readiness probes - they were failing. Application is working. After migrating to CD17/EAP73 image pod will be restarting and application will be down.
[0] https://issues.jboss.org/browse/CLOUD-1988
[1] https://issues.jboss.org/browse/CLOUD-3248
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months
[JBoss JIRA] (SWSQE-929) Molecule maistra-e2e Not Running On AWS
by Guilherme Baufaker Rêgo (Jira)
[ https://issues.jboss.org/browse/SWSQE-929?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo resolved SWSQE-929.
-------------------------------------------
Resolution: Done
[~mmahoney]
Sorry for the delay.
It was a small problem on the template.
I fixed.
Please delete your local copy of the branch and do a git pull again of molecule branch.
It should be there.
> Molecule maistra-e2e Not Running On AWS
> ---------------------------------------
>
> Key: SWSQE-929
> URL: https://issues.jboss.org/browse/SWSQE-929
> Project: Kiali QE
> Issue Type: Task
> Reporter: Matthew Mahoney
> Assignee: Guilherme Baufaker Rêgo
> Priority: Major
> Labels: infrastructure
>
> Need to be able to run Molecule tests on AWS, but currently tests fail because access quay.io/maistra/kiali-operator is not authorized
> Ex:
> Failed to pull image "quay.io/maistra/kiali-operator:1.0.5": rpc error: code = Unknown desc = Error reading manifest 1.0.5 in quay.io/maistra/kiali-operator: unauthorized: access to the requested resource is not authorized
> Note:
> The Secret is present and the following lines are not commented
> secret_file_path: "{{ lookup('env', 'MOLECULE_PROJECT_DIRECTORY') }}/molecule/maistra-e2e/assets/secret.yaml"
> secret: "{{ lookup('template', secret_file_path) | from_yaml }}"
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 11 months