To be able to debug java apps you need to add special options for JVM, usually that can be done using JAVA_OPTIONS
Here is a few links do understand how it works
- debugging - What are Java command line options to set to allow JVM to be remotely debugged? - Stack Overflow
Thanks for the information, Vlad,
I'm trying to work through this info and see if I can get things working. When running Wildfly in debug mode, do you know if you should be able to telnet to the debug port and confirm that it is listening on it? I've tried setting the --debug startup option on my server settings and can see some differences in the logging information that shows up, seeming to indicate that it recognizes the debug switch. When I try to telnet to the debug port, however, it doesn't seem to indicate anything listening on it.
After reviewing the information I have thus far, it looks like what I really need to diagnose is down inside the Undertow Core, Specifically down in:
Interestingly, I cannot seem to find that class anywhere in the wildfly 10 source download, so I am wondering if I am on the wrong track to try and diagnose this. Would you expect that undertow core to be included in the full wildfly source download?
I just have downloaded wildfly 10 and see that default debug port is 8787, if you want to set another port you just need to enter ./standalone.sh --debug 9797
That you can read in the wildfly-10.0.0.Final/bin/standalone.sh(bat) files
According to open port I can see it and connect in the IDE:
netstat -nap | grep 8787
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:8787 0.0.0.0:* LISTEN 8185/java
About your second question - InMemorySessionManager
This guy is available and located in the wildfly modules
wildfly-10.0.0.Final$ grep -rl 'InMemorySessionManager'
Thanks for all that info, Vlad,
I'm using a customized version of the server, and I wonder if something that we have tailored prevents the debugging mode to work right? I will try again using the netstat approach and see if that reveals anything more.
One thing I have noticed from looking at the source is that there is some pretty detailed logging down inside that session manager, but for the life of me I cannot figure out how to get it turned on. If I could see that info, it might help me better understand what is going on. Are you familiar with how to control this logging down inside undertow?
To be able to customize logging you need to read this one Logging Configuration - WildFly 10 - Project Documentation Editor
The main idea is that you need to add something like this
<!--here you can specify own handler -->
Thanks for that info, Vlad. At last, I can see the trace logging messages from the session manager!
I had tried adding the logger category before, but completely overlooked the fact that I had an INFO level specified as part of the console handler. This resulted in the messages being filtered from the console display while the messages were all the time getting placed in the external log FILE because that handler did not have level within the definition. Lesson learned there on logging hierarchy for sure.
So I can now see all the session manager trace diagnostics related to the timeouts...I just need to see now if that helps me understand why AJAX requests sent from my pages don't result in bumping the timeout for the primary session the user is logged in with. Fingers crossed that it is something obvious.
Thanks so much for your help in getting me this far.
Your feedback has helped me to solve my issue, but not in the way I expected. After I finally got the detailed trace working, I could see that the session timeout was indeed being bumped up correctly by my AJAX calls. After confirming that, it redirected my focus back to exactly how the flow events was getting to the logout action, and I discovered a meta tag that was getting added to the pages for an autorefresh to the logout action using the session expiration as the time. That was the culprit all along.
Thanks again for all your help.