Wildfly debugging in Eclipse guidance

[jboydnolan]

I have a web application running on top of Wildfly 10 which is developed in Eclipse. We've encountered a problem where for some reason AJAX style requests are not triggering the reset of the session timeout information like normal browser requests actions do, The net effect is that if you are working in a screen that is interacting with the server through these AJAX requests, the session times out and you are logged out in the middle of active work. I've tried many different actions as part of the AJAX request process, including things like manually resetting the session timeout directly in the request process, but nothing seems to work.

I would like to try and debug this problem inside of Wildfly itself to try and understand why these background requests are not resetting the session timeout, but I have no experience getting that debug level access working through Eclipse. Someone shared with me a few months ago the Wildfly core code location where the sessions lifecycle is handled, I just don't know how to properly debug it.

Can anyone provide me some guidance on how to do this, or perhaps point me to an existing article or discussion that covers it? I'm hoping that it might be as simple as importing the Wildfly core source into my existing Eclipse workspace, but again I am uncertain the proper way to go about it.

Any guidance would be greatly appreciated.

Boyd

[zhurlik]

Hi,

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
• https://www.packtpub.com/sites/default/files/downloads/2432OS_Appendix.pdf
• https://blog.codeleak.pl/2017/06/remote-debugging-wildfly-application-in.html

Thanks,

Vlad

[jboydnolan]

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:

undertow/core/src/main/java/io/undertow/server/session/InMemorySessionManager.java

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?

Best Regards,

Boyd

[zhurlik]

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'

modules/system/layers/base/io/undertow/servlet/main/undertow-servlet-1.3.15.Final.jar

modules/system/layers/base/io/undertow/core/main/undertow-core-1.3.15.Final.jar

[jboydnolan]

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?

Boyd

[zhurlik]

Hi,

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

<logger category="io.undertow">

   <level name="DEBUG"/>

   <!--here you can specify own handler -->
   <handlers>

   <handler name="CONSOLE"/>

   <handler name="FILE"/>

   </handlers>

</logger>

Thanks,

Vlad

[jboydnolan]

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.

Boyd

[jboydnolan]

Hey, Vlad,

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.

Boyd