-
Notifications
You must be signed in to change notification settings - Fork 466
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WFCORE-7008] Split ManagementInterfaceResourcesTestCase for different stability levels. #6199
base: main
Are you sure you want to change the base?
Conversation
0aacaa4
to
19320af
Compare
All tests run locally on Linux, just added a test that does nothing to check if the setup and cleanup works. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
try { | ||
task.setup(client); | ||
test.run(); | ||
controller.reload(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reload here seems unnecessary, doesn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure at the moment, the original tests also had this reload.
The problem with this test is we deliberately exhaust the http management interface connection to test that this configuration is working and then we try and use the connection to perform further updates.
...ava/org/wildfly/core/test/standalone/mgmt/ManagementInterfaceResourcesCommunityTestCase.java
Show resolved
Hide resolved
@RunWith(WildFlyRunner.class) | ||
@ServerControl(manual = true) | ||
public abstract class AbstractManagementInterfaceResourcesTestCase { | ||
protected static final Logger LOG = Logger.getLogger(ManagementInterfaceResourcesTestCase.class.getName()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor, this log should be in the child's classes instead of the parent's.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I was expecting a log on each child class so it can be easier to track which one is being executed, but in case of a stack trace, we can inferred the origin class from the stack, so I am fine with whatever you prefer
Weird, Linux - Security Manager - JDK 11 has failed twice on the test developed for this PR |
…t stability levels.
The purpose is to verify the setup and cleanup work as expected.
I am still getting intermittent failures with these tests running locally, I am not sure why, so let's see how the CI behaves |
This comment was marked as outdated.
This comment was marked as outdated.
It does look to be something security manager related quite consistently failing this test. |
@darranl I wonder if somehow not all the sockets, or at least a number that would allow open a new one to properly do the reload, could be the issue. We close them from the point of view of one pair, but we proceed to the reload without being sure they have been fully closed on the other pair (server side), just an idea in case it sounds your bell |
Core -> WildFly Preview Integration Build 14038 outcome was FAILURE using a merge of ad0e7ed |
Being only security manager affected now feels like there is a specific target to debug. The other kind of brute force option here would be to also define the native management interface on the server under test and use that for the server management ops so even if we exhaust the resources on the http management interface we can always access the native one for server control. A big issue with this kind of test is it is also heavily dependent on the behaviour of the underlying TCP stack on the target system handling a lot of clean up. Where resource constrained I don't know if the target is more or less likely to proactively clean up half closed sockets. |
Core -> WildFly Preview Integration Build 14039 outcome was FAILURE using a merge of ad0e7ed |
I tried with |
Core -> Full Integration Build 14261 outcome was FAILURE using a merge of ad0e7ed |
Core -> Full Integration Build 14262 outcome was FAILURE using a merge of ad0e7ed |
There has been no activity on this PR for 45 days. It will be auto-closed after 90 days. |
/retest |
Core -> WildFly Preview Integration Build 14278 outcome was FAILURE using a merge of ad0e7ed Failed tests
|
Core -> Full Integration Build 14497 outcome was FAILURE using a merge of ad0e7ed Failed tests
|
https://issues.redhat.com/browse/WFCORE-7008