honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/x-pack/qa/evil-tests/build.gradle

12 lines
331 B
Groovy
Raw Normal View History

Protect scheduler engine against throwing listeners (#32998) There are two problems with the scheduler engine today. Both relate to listeners that throw. The first problem is that any triggered listener that throws a plain old exception will cause no additional listeners to be triggered for the event, and will also cause the scheduler to never be invoked again. This leads to lost events and is bad. The second problem is that any triggered listener that throws an error of the fatal kind will not lead to that error because caught by the uncaught exception handler. This is because the triggered listener is executed as a future task under a scheduled thread pool executor. A throwable there goes caught by the JDK framework and set as the outcome on the future task. Since we never inspect these tasks for their outcomes, nor is there a good place to do this, we have to handle these errors ourselves. To do this, we catch them and dispatch them to the uncaught exception handler via a forked thread. This is similar to our handling in Netty.
2018-08-20 22:07:16 -04:00
apply plugin: 'elasticsearch.standalone-test'
dependencies {
[Kerberos] Move tests based on SimpleKdc to evil-tests (#33492) We have a test dependency on Apache Mina when using SimpleKdcServer for testing Kerberos. When checking for LDAP backend connectivity, the code checks for deadlocks which require additional security permissions accessClassInPackage.sun.reflect. As this is only for test and we do not want to add security permissions to production, this commit moves these tests and related classes to x-pack evil-tests where they can run with security manager disabled. The plan is to handle the security manager exception in the upstream issue DIRMINA-1093 and then once the release is available to run these tests with security manager enabled. Closes #32739
2018-09-13 20:07:19 -04:00
testCompile project(path: xpackModule('core'), configuration: 'testArtifacts')
testCompile project(path: xpackModule('security'), configuration: 'testArtifacts')
Protect scheduler engine against throwing listeners (#32998) There are two problems with the scheduler engine today. Both relate to listeners that throw. The first problem is that any triggered listener that throws a plain old exception will cause no additional listeners to be triggered for the event, and will also cause the scheduler to never be invoked again. This leads to lost events and is bad. The second problem is that any triggered listener that throws an error of the fatal kind will not lead to that error because caught by the uncaught exception handler. This is because the triggered listener is executed as a future task under a scheduled thread pool executor. A throwable there goes caught by the JDK framework and set as the outcome on the future task. Since we never inspect these tasks for their outcomes, nor is there a good place to do this, we have to handle these errors ourselves. To do this, we catch them and dispatch them to the uncaught exception handler via a forked thread. This is similar to our handling in Netty.
2018-08-20 22:07:16 -04:00
}
Converting randomized testing to create a separate unitTest task instead of replacing the builtin test task (#36311) - Create a separate unitTest task instead of Gradle's built in - convert all configuration to use the new task - the built in task is now disabled
2018-12-19 01:25:20 -05:00
unitTest {
Protect scheduler engine against throwing listeners (#32998) There are two problems with the scheduler engine today. Both relate to listeners that throw. The first problem is that any triggered listener that throws a plain old exception will cause no additional listeners to be triggered for the event, and will also cause the scheduler to never be invoked again. This leads to lost events and is bad. The second problem is that any triggered listener that throws an error of the fatal kind will not lead to that error because caught by the uncaught exception handler. This is because the triggered listener is executed as a future task under a scheduled thread pool executor. A throwable there goes caught by the JDK framework and set as the outcome on the future task. Since we never inspect these tasks for their outcomes, nor is there a good place to do this, we have to handle these errors ourselves. To do this, we catch them and dispatch them to the uncaught exception handler via a forked thread. This is similar to our handling in Netty.
2018-08-20 22:07:16 -04:00
systemProperty 'tests.security.manager', 'false'
[Kerberos] Move tests based on SimpleKdc to evil-tests (#33492) We have a test dependency on Apache Mina when using SimpleKdcServer for testing Kerberos. When checking for LDAP backend connectivity, the code checks for deadlocks which require additional security permissions accessClassInPackage.sun.reflect. As this is only for test and we do not want to add security permissions to production, this commit moves these tests and related classes to x-pack evil-tests where they can run with security manager disabled. The plan is to handle the security manager exception in the upstream issue DIRMINA-1093 and then once the release is available to run these tests with security manager enabled. Closes #32739
2018-09-13 20:07:19 -04:00
include '**/*Tests.class'
Protect scheduler engine against throwing listeners (#32998) There are two problems with the scheduler engine today. Both relate to listeners that throw. The first problem is that any triggered listener that throws a plain old exception will cause no additional listeners to be triggered for the event, and will also cause the scheduler to never be invoked again. This leads to lost events and is bad. The second problem is that any triggered listener that throws an error of the fatal kind will not lead to that error because caught by the uncaught exception handler. This is because the triggered listener is executed as a future task under a scheduled thread pool executor. A throwable there goes caught by the JDK framework and set as the outcome on the future task. Since we never inspect these tasks for their outcomes, nor is there a good place to do this, we have to handle these errors ourselves. To do this, we catch them and dispatch them to the uncaught exception handler via a forked thread. This is similar to our handling in Netty.
2018-08-20 22:07:16 -04:00
}