[JBoss JIRA] (SWSQE-576) run-python3-ui-tests job sometimes stuck
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-576?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-576:
-------------------------------------
Only open connection by the python process was to OS master where the kiali was running - pytest 200 default 4u IPv4 174989736 0t0 TCP 10.130.1.195:48252->10.16.23.11:pcsync-https (ESTABLISHED).
No stuck connection to zalenium. I killed the connection to OS master but the python process was still running.
> run-python3-ui-tests job sometimes stuck
> ----------------------------------------
>
> Key: SWSQE-576
> URL: https://issues.jboss.org/browse/SWSQE-576
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Minor
>
> run-python3-ui-tests is sometimes stuck after the tests finish. The pytest process is still running on the jenkins slave. Probably there is some connection which is not closed - maybe to zalenium?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (SWSQE-576) run-python3-ui-tests job sometimes stuck
by Filip Brychta (Jira)
[ https://issues.jboss.org/browse/SWSQE-576?page=com.atlassian.jira.plugin.... ]
Filip Brychta commented on SWSQE-576:
-------------------------------------
Trace of stuck python process
(gdb) bt
#0 0x00007fb41da76adb in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0
#1 0x00007fb41da76b6f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2 0x00007fb41da76c0b in sem_wait@(a)GLIBC_2.2.5 () from /lib64/libpthread.so.0
#3 0x00007fb41ddf3ced in PyThread_acquire_lock_timed () from /lib64/libpython3.6m.so.1.0
#4 0x00007fb41ddf8c1c in acquire_timed () from /lib64/libpython3.6m.so.1.0
#5 0x00007fb41ddf8d97 in lock_PyThread_acquire_lock () from /lib64/libpython3.6m.so.1.0
#6 0x00007fb41dd3ca0f in _PyCFunction_FastCallDict () from /lib64/libpython3.6m.so.1.0
#7 0x00007fb41ddb2363 in call_function () from /lib64/libpython3.6m.so.1.0
#8 0x00007fb41ddb64c4 in _PyEval_EvalFrameDefault () from /lib64/libpython3.6m.so.1.0
#9 0x00007fb41ddb1f45 in _PyEval_EvalCodeWithName () from /lib64/libpython3.6m.so.1.0
#10 0x00007fb41ddb20c8 in fast_function () from /lib64/libpython3.6m.so.1.0
#11 0x00007fb41ddb22f6 in call_function () from /lib64/libpython3.6m.so.1.0
#12 0x00007fb41ddb64c4 in _PyEval_EvalFrameDefault () from /lib64/libpython3.6m.so.1.0
#13 0x00007fb41ddb1f45 in _PyEval_EvalCodeWithName () from /lib64/libpython3.6m.so.1.0
#14 0x00007fb41ddb20c8 in fast_function () from /lib64/libpython3.6m.so.1.0
#15 0x00007fb41ddb22f6 in call_function () from /lib64/libpython3.6m.so.1.0
#16 0x00007fb41ddb64c4 in _PyEval_EvalFrameDefault () from /lib64/libpython3.6m.so.1.0
#17 0x00007fb41ddb15e0 in _PyFunction_FastCall () from /lib64/libpython3.6m.so.1.0
#18 0x00007fb41ddb22f6 in call_function () from /lib64/libpython3.6m.so.1.0
#19 0x00007fb41ddb64c4 in _PyEval_EvalFrameDefault () from /lib64/libpython3.6m.so.1.0
#20 0x00007fb41ddb15e0 in _PyFunction_FastCall () from /lib64/libpython3.6m.so.1.0
#21 0x00007fb41ddbb576 in _PyFunction_FastCallDict () from /lib64/libpython3.6m.so.1.0
#22 0x00007fb41dcf297e in _PyObject_FastCallDict () from /lib64/libpython3.6m.so.1.0
#23 0x00007fb41dcf2bae in _PyObject_Call_Prepend () from /lib64/libpython3.6m.so.1.0
#24 0x00007fb41dcf288b in _PyObject_FastCallDict () from /lib64/libpython3.6m.so.1.0
#25 0x00007fb41dd54f5d in slot_tp_finalize () from /lib64/libpython3.6m.so.1.0
#26 0x00007fb41ddf73c1 in collect () from /lib64/libpython3.6m.so.1.0
#27 0x00007fb41ddf7bdd in collect_with_callback () from /lib64/libpython3.6m.so.1.0
#28 0x00007fb41ddf8186 in PyGC_Collect () from /lib64/libpython3.6m.so.1.0
#29 0x00007fb41dddae85 in Py_FinalizeEx () from /lib64/libpython3.6m.so.1.0
#30 0x00007fb41dddbc08 in Py_Exit () from /lib64/libpython3.6m.so.1.0
#31 0x00007fb41dddebb5 in handle_system_exit.part.3 () from /lib64/libpython3.6m.so.1.0
#32 0x00007fb41dddefa5 in PyErr_PrintEx () from /lib64/libpython3.6m.so.1.0
#33 0x00007fb41dde0376 in PyRun_SimpleFileExFlags () from /lib64/libpython3.6m.so.1.0
#34 0x00007fb41ddf6733 in Py_Main () from /lib64/libpython3.6m.so.1.0
#35 0x0000000000400a3e in main ()
(gdb)
> run-python3-ui-tests job sometimes stuck
> ----------------------------------------
>
> Key: SWSQE-576
> URL: https://issues.jboss.org/browse/SWSQE-576
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Minor
>
> run-python3-ui-tests is sometimes stuck after the tests finish. The pytest process is still running on the jenkins slave. Probably there is some connection which is not closed - maybe to zalenium?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFCORE-4323) Improve the suspend-timeout test cases
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFCORE-4323?page=com.atlassian.jira.plugi... ]
Jan Stourac updated WFCORE-4323:
--------------------------------
Affects Version/s: 8.0.0.Beta5
> Improve the suspend-timeout test cases
> --------------------------------------
>
> Key: WFCORE-4323
> URL: https://issues.jboss.org/browse/WFCORE-4323
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 8.0.0.Beta5
> Reporter: Yeray Borges
> Assignee: Jan Stourac
> Priority: Major
>
> Right now we are not covering all test cases available when we are using suspend-timeout attributes for the server lifecycle operations.
> Discussions about the existing test cases concluded that we should be using the following strategy to test them effectively:
> - A test case using suspend-timeout <0 -> We can unlock the web application manually. That means test the SuspendController.listeners.complete () event path.
> - A test case using suspend-timeout> 0 -> We should not unlock manually the web application, and we should wait for the timeout, that means to test the SuspendController.listeners.timeout () event path.
> - A test case using suspend-timeout = 0 -> That could become a redundant bit with the previous case because the event will be the SuspendController.listeners.timeout (), but we will not be included in the test that the event is fired as a result of a TimerTask ().
> In order to allow the inflight tasks being stopped in our test suite, we need to change the way we are enabling Undertow in wildfly-core. Right now our TestSuspendServiceActivator is activating Undertow without using the IO worker threads, that means when the server is shutdown/stopped, the tasks created by Undertow are not automatically terminated.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFCORE-4323) Improve the suspend-timeout test cases
by Jan Stourac (Jira)
[ https://issues.jboss.org/browse/WFCORE-4323?page=com.atlassian.jira.plugi... ]
Jan Stourac reassigned WFCORE-4323:
-----------------------------------
Assignee: Jan Stourac (was: Yeray Borges)
> Improve the suspend-timeout test cases
> --------------------------------------
>
> Key: WFCORE-4323
> URL: https://issues.jboss.org/browse/WFCORE-4323
> Project: WildFly Core
> Issue Type: Task
> Components: Test Suite
> Reporter: Yeray Borges
> Assignee: Jan Stourac
> Priority: Major
>
> Right now we are not covering all test cases available when we are using suspend-timeout attributes for the server lifecycle operations.
> Discussions about the existing test cases concluded that we should be using the following strategy to test them effectively:
> - A test case using suspend-timeout <0 -> We can unlock the web application manually. That means test the SuspendController.listeners.complete () event path.
> - A test case using suspend-timeout> 0 -> We should not unlock manually the web application, and we should wait for the timeout, that means to test the SuspendController.listeners.timeout () event path.
> - A test case using suspend-timeout = 0 -> That could become a redundant bit with the previous case because the event will be the SuspendController.listeners.timeout (), but we will not be included in the test that the event is fired as a result of a TimerTask ().
> In order to allow the inflight tasks being stopped in our test suite, we need to change the way we are enabling Undertow in wildfly-core. Right now our TestSuspendServiceActivator is activating Undertow without using the IO worker threads, that means when the server is shutdown/stopped, the tasks created by Undertow are not automatically terminated.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months
[JBoss JIRA] (WFLY-11698) TransactionTimeoutQueueSetupTask fails to set up max-delivery-attempts properly
by Ivo Studensky (Jira)
Ivo Studensky created WFLY-11698:
------------------------------------
Summary: TransactionTimeoutQueueSetupTask fails to set up max-delivery-attempts properly
Key: WFLY-11698
URL: https://issues.jboss.org/browse/WFLY-11698
Project: WildFly
Issue Type: Bug
Components: Test Suite
Affects Versions: 16.0.0.Beta1
Reporter: Ivo Studensky
Assignee: Ivo Studensky
{{org.jboss.as.test.integration.ejb.transaction.mdb.timeout.TransactionTimeoutQueueSetupTask}} fails to set up {{max-delivery-attempts}} properly.
It uses a shared ModelNode without cloning it and also does not set up enough properties in order to take effect.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 7 months