I wrote myself a server monitoring utility using Vaadin 18.0.2 for the UI. This works very nicely execpt for one major issue:
The monitoring is meant to become part of our "team-screen", i.e. a big screen displaying team news, build results, server status, etc.). As such the application has be able to run for longer periods without any user interaction.
The application once per minute queries a bunch of servers re. livelihood and response times and then updates a corresponding result screen. For some reason it always crashes after pretty reproducibly 80 minutes with a com.vaadin.flow.component.UIDetachedException:
com.vaadin.flow.component.UIDetachedException: null
at com.vaadin.flow.component.UI.handleAccessDetach(UI.java:412)
at com.vaadin.flow.component.UI.access(UI.java:512)
at com.vaadin.flow.component.UI.access(UI.java:499)
...
Once this happens all subsequent UI updates have the same issue, i.e. the display "freezes".
The above code is called by a listener which always first requests a Vaadin UI handle and then updates the screen. While it keeps getting such a UI there obviously something's wrong with it after these 80 minutes and then - while the application's monitoring core continues to run - all UI updates are impossible. Neither reloading the page in the browser or even terminating and restarting the browser helps. The application's web-interface is "dead" after that and only an application restart can revive it. This is of course a complete killer or "no-go" for this kind of application. :-(
I suspect that there is some session timeout or UI object duration limit being reached but I haven't encountered any setting to control that so far. I also found no docs mentioning that some token or handle or similar needs to be regularly refreshed or so.
What I specifically don't understand is, why a browser page reload or even a browser restart doesn't help here. One doesn't get a login-in screen as one might expect if some token or session cookie would have expired or so, but the application's web interface is completely "dead" after that time. One doesnt even get any response anymore from the server but the browser requests just time out...
Any hint or guidance what could be the cause for these exceptions or what mechanism is behind this behavior?
Related
I have a MVC application that stores some information in memory and writes that data asynchronously to a database.
This mechanism works fine. However, I want to prevent an IISreset or a reboot to flush the data before it is written.
Is there a way to receive an event to tell IIS and/or the OS to run some handling code prior to shutting down?
(Update): I am fully aware that I will never be able to detect a crash, hard reset etc. Losing some data on a hard reset is not nice but I will deal with it (and make sure the application is usable after the server comes back).
Use the "office metaphor" to describe my approach: If you receive a BSOD, your work is lost if you haven't saved. But if you shutdown the way you should, you will be asked to save before.
I am using Loadrunner to test the webpage(which we built). The problem here i am facing is after execution of the test, the loadrunner reports were showing too high response time for login page(1st page after entering URL) and after login page like 20-30 seconds. But manually its not even taking 2 seconds. Can anyone explain me why like this?
1) Check whether application sending parallel request to the server.
if yes, Use web_concurrent_start() and web_concurrent_end() function.Which supports only 'url' mode recording.
When user launches the multiple browser instance from same machine.It will give more response time. It depends on application, you have to check with Development team.
I wants to do some operations even after closing the session (manual or by instant). I can do whatever I want when the user clicking the link 'logout' but I don't see any option do the same when the user suddenly closing the browser.
Hence, I am looking for any listener kind of things similar in Java.
in Java:
http://www.mkyong.com/servlet/a-simple-httpsessionlistener-example-active-sessions-counter/
Rails is stateless and doesn't support this type of behaviour directly.
If your requirement can only be satisfied with this type of logic, then I can think of a number of ways you could work around this:
Have the page continuously ping your server to let it know the
connection is still alive. Run a cron job every reasonable interval
to take whatever action you want on terminated sessions.
Or just say that any session not refreshed after 30 minutes or
something is considered terminated.
Create a javascript code run on page unload that notifies your app that
the browser is closing. This is obviously not foolproof (connection
drops, browser crashes, etc) and probably isn't viable.
NOTE: This is more of a "philosophical" question than a technical one.
So, I'm writing an iPad app which syncs its data to a backend which I also wrote. The sync works well, on a good network like the one at my apartment.
But in a slow or otherwise mediocre network like the public one in a Starbucks or my office it has a tendency to error out. In my testing, when it fails (albeit, infrequently) on these mediocre networks it's a timeout or "could not connect to the server" scenario, and the second attempt has consistently succeeded, resulting in a successful sync.
So my question is about how or whether to report these errors to the user. Right now I quietly report all errors to the user ( using an unobtrusive error mark, not a modal dialog ), but it's annoying in these scenarios because the next sync (has so far) always succeeded.
For some context: My app syncs in the background, continuously, as local changes are spotted and pushed to the server and as a long-polling background thread watches for changes on the server and pulls them downstream to the app.
My thought is that when I sync, I should try (for example) 3 times, breaking out on the first successful attempt. Only if all three attempts fail should I report an error to the user.
Is this a reasonable idea? Or is this a terrible idea?
Thanks,
I have an MVC project, and I'm looking at speeding things up. One thing I'm scratching my head over is the BeginProcesRequest() which I have no control over. Using New Relic I found that this method is, on average consuming 90% of the time required for the transaction to complete.
The code in my controller is pretty simple. It has a look for an action session for the user and redirects to their dashboard if it finds one. there isn't any database calls on the actual page. The only written is:
if (Session["UserID"] != null)
// Perform actions
The BeginProcessRequest() method takes almost 4 seconds as you can see in the screenshot
This can't be something unique to my site? I'm using a small EC2 instance for the server, and although there are other applications running on the site the CPU and memory stay pretty much at 0 throughout the request.
EDIT - Reviewed the following post:
What happens in BeginProcessRequest()?
However as my application is idle when the most time consuming requests take place I can't see how it could be related to competing threads.
I think the issue was with IIS, as after I changed the property of idle time-out in the application pool to be one day it now seems to load much faster on initial start.
I also explicitly disabled the session state on my home controller, and ensured that SQL Server's auto close parameter was set to off.