-
1. Re: InterruptedIO in wildfly main thread
ctomc Jul 2, 2013 2:31 PM (in response to b.eckenfels)1 of 1 people found this helpfulI fixed the hacking on wildfly wiki, as the link to as7-dev forum should not even be used for as7 and i have moved this thread to wildfly forum.
-
2. Re: InterruptedIO in wildfly main thread
brian.stansberry Jul 2, 2013 3:39 PM (in response to b.eckenfels)Thanks for the post!
I think the thing to do in that catch block is Thread.currentThread().interrupt() and then break, allowing termination. (The Thread.currentThread().interrupt() call is just to follow best practice on not swallowing interrupted exceptions.) If a thread has somehow interrupted the main thread, that's an indication termination is desired and I don't see any reason to ignore it.
As for the client.reconnect() part, I want to talk to Emanuel Muckenhuber, but I think the thing to do is to have HostControllerClient.reconnect simply not throw exceptions other than InterruptedIOException. It already has logic for dealing with connection failure by putting the server in restart-required state. The use of that logic could be expanded to cover exception cases.
I also think in DomainServerMain the System.exit(ExitCodes.NORMAL) call once the loop terminates should be changed to take a variable, set to ExitCodes.FAILED in the catchall "catch (Exception e)" block.
-
3. Re: InterruptedIO in wildfly main thread
b.eckenfels Jul 3, 2013 5:22 PM (in response to brian.stansberry)Brian Stansberry wrote:
I think the thing to do in that catch block is Thread.currentThread().interrupt() and then break, allowing termination. (The Thread.currentThread().interrupt() call is just to follow best practice on not swallowing interrupted exceptions.) If a thread has somehow interrupted the main thread, that's an indication termination is desired and I don't see any reason to ignore it.
I agree and can provide a patch for that. I am a bit unsure about restoring the interruption flag, as the shutdown code should not be interrupted again. But then, the rest of the function is reasonable short so we will not run into any method which barfs on it.
As for the client.reconnect() part, I want to talk to Emanuel Muckenhuber, but I think the thing to do is to have HostControllerClient.reconnect simply not throw exceptions other than InterruptedIOException. It already has logic for dealing with connection failure by putting the server in restart-required state. The use of that logic could be expanded to cover exception cases.
Ok, in that case I will acknowledge that with a short comment.
I also think in DomainServerMain the System.exit(ExitCodes.NORMAL) call once the loop terminates should be changed to take a variable, set to ExitCodes.FAILED in the catchall "catch (Exception e)" block.
Ok, I somewhat wonder if losing the parent is actually a "normal" condition. I guess the normal server shutdown is signaled from the HC and executed in some other place. That would mean that all code patch in the main() method would be non-NORMAL. But if you think it should differentiate, I can do that. I was thinking about setting the exitState to NORMAL after the future has returned the service. (And resetting it to error in case of (non-Interrupted and non-EOF) exceptions).
Should I open a JIRA Bug for it?
An related question: is it possible/safe to use the logger in this place? I really think we should log the reason for the exit code decision there.
-
4. Re: InterruptedIO in wildfly main thread
b.eckenfels Jul 4, 2013 4:59 PM (in response to b.eckenfels)Hello,
I have started a branch, which is supposed to address this point. It can be found here. Right now it is only adding a break on Interrupted State and pulled the Future dereference into the proper try block. I am still investigating on the normal control flow on reconnect/shutdown, thats why I havent added the ExitCode change yet.
https://github.com/ecki/wildfly/compare/topic-mainfix?expand=1
Greetings
Bernd