Hi all,
Am getting pretty stuck here, and could use some help. In
another thread
, I asked about having sessions expire when using the Refresher add on. I have a workaround for the session expiration problem, which almost always works:
- Implement HttpServletRequestListener and Refresher.RefreshListener.
- When a call come into onRequestStart(), note the current time as “lastRequestTime” or something.
- In the refresher listener, check to see if the current time is 30 minutes later than lastRequestTime.
3.a. If so, invalidate the session (can’t do it in onRequestStart due to
this issue
).
3.b. If not, discard the previous “lastRequestTime” because it wasn’t user-initiated.
In other words, I manually track calls from the client and try to ignore the ones from the refresher. Because I have to invalidate the session in the refresher listener, it does mean that the timeout can happen X seconds later than I want, where X is the refresh period, but that’s not a big deal.
What I’m seeing now is that some components in our app are making calls back to the server even though there was no user action. I log the calls to request start/end methods, refresher listener, etc, and see start/refresh/end, which is great. But after doing some work in the app and populating some tables, I see something like: start/refresh/end followed by start/end (or multiple start/end pairs) that are
not
calls to the refresher listener.
They always happen after the refresher call. Something is telling a widget to make another call back to the server after the refresh, and that’s circumventing my session timeout code. Can anyone tell me how to figure out what’s going on here?
I’ve watched the on-the-wire traffic, grabbed what I thought was the PID of the component making the request, and saw that it was a table by drilling down in the Vaadin browser-side debugger. But what would make the table do this? I’d really like to shut that off if I can, or at least ignore the calls when dealing with session timing. How can I determine the source of a request from within my application?
I thought I could do this by debugging the changeVariables() method in AbstractCommunicationManager, but I have to run this app remotely and debugging that way is almost impossible. Even if I determine that it’s component X or Y in the debugger, how do I recognize that same request/component in my app so I can ignore the request in terms of timing?
I know it’s a lot of info, but I’ve been at it for a couple days and feel like someone else must have had a similar need to check the source of a request at the app layer.
Thanks,
Bobby
p.s. I suppose if I can’t figure this out correctly, I can ignore refresher requests
and
any request that comes in within 1 second or so of the refresher request end, but that’s a bit hacky and there’s always some chance that a user will time out due to bad timing.