I use google analytics to track user behaviour in an application. What I do is this:
Send a start session
Send a custom event "Lifetime start"
If there is an error: send a fatal exception
Send a custom event "Lifetime stop"
Send a stop session
Now when I look at the statistics, I see that a certain percentage of users had an exception over tha last 30 days. However, all users have had sessions without exception!. This is almost impossible, since I know there are users where the application crashes every time.
Is it possible that the fatal exception I submit terminates the session? So even users where the app crashes everytime get a second (short) session, containing only the "Lifetime stop" custom event? (That would explain my statistics)
That being said, I ran a test using Universal Analytics via the web (so this was not done in an app), but the results should be consistent with your setup.
I started a session and sent a "Before Exception" event which showed up in my real-time event report. I then waited a few seconds and successfully sent a fatal exception (which there is not a real-time report for). Without refreshing I then sent an "After Exception" event which came through fine in my real-time report.
From the following screenshot (User Explorer), you can see the two "Exception Test" events that I described both in the same session.
I would think that whatever fatal crash you're seeing is what is preventing additional data from appearing in Google Analytics- not that Google Analytics is ending the session at the time of the fatal exception. If it was ending the session, you'd still see events for "Lifetime stop", but it sounds like you aren't seeing those events at all.
The only things that end a GA session:
Session timeout (default: 30 minutes)
End of day
UTM/AdWords/Referral
Manually ending the session as you described
You may need to come up with some context clues to actually get to the bottom of this (maybe a remote server log?), but from the information provided (and if I'm understanding it correctly) I'm leaning towards the crash preventing the rest of the code from running.
Related
I've had Application Insights set up on my ASP.NET project for a couple months with no issues. I use Custom Events for logging certain events.
Recently, I tried to add a Custom Event after a user has authenticated in order to track the login behavior. My custom event DOES log to application insights debug session. I know this because I can see it in the telemetry when paused on a breakpoint just after the event.
However, when I continue running the application, my custom event no longer shows up the telemetry. It just disappears.
I cannot understand what the issue is. Does anyone familiar have any (application) insights? I couldn't help myself ;)
There are some things to check:
are you logging to one resource (iKey) and searching on another? (a lot of people send data to one resource in dev/debug and a different resource in release/prod environments. so make sure you're sending to the place you expect, and searching the place you expect.
is the data actually going out successfully? you may need to use fiddler or some other tool to watch your outbound http for calls to dc.services.visualstudio.com. It could somehow be the case that there's something wrong with the data you're sending, or maybe you're getting capped or throttled by the service. If that's the case, the outbound requests will have responses other than 200, and will generally tell you the reason it didn't accept any items that it rejected.
if the data is getting successfully sent and is going where you expect it to go, there might just be a delay in backend processing. you can always check aka.ms/aistatus to see if there are any current issues with the service.
I am confused, however, by what you mean when you say
However, when I continue running the application, my custom event no longer shows up the telemetry. It just disappears.
What do you mean "it just disappears" ? if you see it in the output window, then the SDK saw it, and it will get sent, precluding any of the above 3 items. Where is it "disappearing" from? unless you clear the output window, it's never gone from there. If you're talking about the VS search tools that show data sent by the AI SDK during debug, that tool currently has a cap of the most recent 250 items that have occurred during the debug session.
Background
I have a batch processing system that needs to send out messages (via SMS/Email) to groups of people.
As our message publihsing system is fairly slow, when the user hits the "send" button, the system posts all the message informtion into a database with a "batch ID" and then does an Asynchronise call (WebRequest.BeginGetRequest) to a "ProcesBatch" ASHX handler request, with the batch ID as a URL request parameter.
This releases the front end page back to the user to do the next batch of messages as the users dont actually need any feedback, however, the recording in the database is subsequently used in a reporting module.
In the mean time, the batch process handler simply cycles around the records from the database for the given batch ID and then posts the messages to our (slow) message publisher sequentially.
The Problem
The problem is that during the batch processing, asp.net is throwing a
System.Threading.ThreadAbortException: Thread was being aborted.
half way through and the remaining messages are not sent.
I have checked IIS and the recycle mins is set at the default 1740 so is there anything else that would cause this?
Or is there a more appropriate way to approach this.
Have you tried to increase executionTimeout under httpRuntime in web.config?
The default value is 90 or 110 seconds (depending .net version).
Perhaps your ashx requires more time to end its job
http://msdn.microsoft.com/en-us/library/vstudio/e1f13641(v=vs.100).aspx
Edit: in general it's not a good idea to set a very long executionTimeout. As other users suggested, consider to develop a Windows Service to do the long jobs.
(Cross posting from Server Fault where I wasn't getting any traction):
I have been trying to chase down the root cause of a condition where ASP .NET session state remains locked after a web request has been terminated due to an unexpected error. We use the SQL Server session state provider for session because we have several servers in a web farm. This issue first presented itself in the form of many requests getting stuck on the 'AcquireRequestState' event of their lifecycle for no apparent reason. I was able to finding corresponding entries for these requests in the session state database in SQL server that were all locked (column Locked = 1). I was also able to correlate these requests to entries in the IIS log with HTTP status codes of 500 (with a sub status of 0). These findings lead me to believe that, in some cases, a request was erroring out but was NOT releasing its lock on session state like it should.
I enabled Failed Request Tracing in IIS for the website in question for status code 500 with all available providers selected each with the 'Verbose' setting for verbosity. I've since gathered several failed traces that have caused permanently locked ASP .NET sessions. They all share the same characteristics:
They are all 'POST' requests where the browser is posting data to be processed/saved.
They all have events indicating that the 'Session' module was invoked during the REQUEST_ACQUIRE_STATE event. At this point the request would have marked the row in the session state database as being "locked". This is normal and expected.
They all have GENERAL_READ_ENTITY_START, GENERAL_READ_ENTITY_END, and GENERAL_REQUEST_ENTITY entries that appear to be reading in the data that was posted to the server as part of the request. This appears to be a buffered operation as these events get repeated over and over with each one reading in some subset of the posted data.
At some point during the 'read entity' related events an error occurs. Some have the error code "Incorrect function. (0x80070001)" and others have "The I/O operation has been aborted because of either a thread exit or an application request. (0x800703e3)".
Once the error has been encountered, they all jump directly to the END_REQUEST events.
The issue here is that, under normal circumstances, there should be a RELEASE_REQUEST_STATE event that will allow the Session module to release the lock it has on the session. This event is being skipped in this scenario. Just to be sure, I enabled failed request tracing for the '200' status code as well and generated several traces of successful requests that do have the RELEASE_REQUEST_STATE event being handled by the Session module.
A co-worker pointed out that you can also cause a request to skip directly to the 'END_REQUEST' event by calling HttpContext.Current.ApplicationInstance.CompleteRequest(). I tested this out and saw that using this method during a post request creates a trace very similar to the ones I've been capturing when this issue has been happening, but session does still get cleaned up properly. This lead to me to running SQL Profiler on the SQL Server database where the session is stored to trace all calls to stored procedures. When we skip directly to END_REQUEST due to calling CompleteRequest(), a call is made to update the session state (and release the lock) as expected. When we skip to END_REQUEST as a result of an error during GENERAL_REQUEST_ENTITY, the call to update or release the lock on session state is never made.
My theory at this point is that some kind of network issue is causing the 'Incorrect function' and 'I/O operation has been aborted because of either a thread exit or an application request' errors, but I don't understand why this seems to be causing the request handling to skip over the releasing the lock on session state. If the request went through REQUEST_ACQUIRE_STATE it seems like it should also release the lock at some point toward the end of the request as well. I'm loathe to say that this is a bug in IIS or ASP .NET, but it certainly appears that way to me at this point.
Are there any known conditions under which errors will lead to a session state lock not being released?
As it turns out, this was related to this question: ManagedPipelineHandler for an AJAX POST crashes if an IE9 user navigates away from a page while that call was in progress
The workaround specified in the accepted answer on that question does work, but Microsoft has also since released a hotfix (not yet publicly available as of this writing) that patches the session handling logic to avoid the issue all together.
I have an ASP.NET application using custom errors. There is one error that occurs that I can't seem to get any information about. When the error happens, it does trigger the custom error page, but for some reason it doesn't trigger Page_Error or Application_Error. If I turn CustomErrors Off completely, I get absolutely no feedback at all. The only feedback I ever have gotten up until now is the redirect to the Custom Error Page.
Scenario: ASP.NET WebForms application. One of the pages has an UpdatePanel with a Submit button. The page works fine. But if I walk away for a while (seems to be 30-60 minutes) and then come back and click the Submit button, nothing happens; no error, no response from the page- nothing. I have not been able to get this to happen while running in the Debugger; it only happens when it is hosted in IIS (7.5). [I've seen other SO posts about this issue but none of the suggestions worked for me.]
When the error happens, with CustomErrors=On or RemoteOnly, the redirect to the custom error page works, and with RemoteOnly, from the server, I get no feedback at all, similar to a remote connection with customerrors=off. I was really hoping for the YSOD error page.
I tried trapping the error in Page_Error by logging the errors to a database, but that didn't work either. I know the Page_Error and the DB portion is working because if I change the submit code behind to do a divide by zero, the error is logged in the DB. Also, the divide by zero error will be displayed to the client with customerrors=off, and with it on it will display the custom error page. But removing the divide by zero error, and then waiting 30 mins or so and trying again, the Page_Error code is not hit, even though it does redirect to the custom error page. I then tried moving the code in the Page_Error to Application_Error, but the exact same thing happens. The forced divide by error works but this seemingly timeout related error does not.
So, are there certain errors that can still trigger the redirect to the custom error page, but will not trigger the Application_Error event?
Thank you John and Sergey! This really was a can of worms. Sergey, you were exactly right- the session timed out. John your idea made me think to look at the Windows Application Event Log rather than trying to track it down in the code. It turned out that my ViewState was expiring when the session timed out, which was set to 20 minutes by default. The exact event log error was:
"Viewstate verification failed. Reason: The viewstate supplied failed integrity check."
Now I was able to manually recycle the app pool and force the error to happen at my leisure which made solving it easier. I wasn't using Session though, at least not on the page in question, so why did this matter? This link was helpful in troubleshooting what was happening.
http://support.microsoft.com/default.aspx?scid=kb;en-us;829743
Buried deep into the article was the following sentence describing a scenario causing the worker process to recycle:
"The application pool is running under an identity other than the Local System account, the Network Service account, or an administrative-level account."
My AppPool is in fact running under a local user account which I created specifically for this purpose. When I changed the AppPool to run with ApplicationPoolIdentity, after recycling the AppPool the ViewState error went away. Then I set the AppPool back to run with the local user account again, gave that account local admin privileges, and this also fixed it. Not wanting to have this user be a local admin, I ended up going with a different solution, which was to generate a machine key for this app so the ViewState MAC is always the same, rather than using the default of auto-generating a new one every time the pool recylces or the session times out. Note this is also what you typically need to do if you have multiple web servers behind a load balancer.
Have problem with Queue time parameter:
1. Have hit.
2. Offline action (phone call started).
3. During conversation visitor comes to site with other source. So the new session started.
4. Phone call ends and I'm sending event with qt parameter = phone call lenghth.
http://www.google-analytics.com/collect?v=1&t=event&tid=UA-74639540-1&cid=1141561565.1464086029&uip=195.138.65.154&ea=call&ec=PROPER&el=119&qt=127
5. Event appears in GA like initiated by last session, while using qt I expect that it will put event in session that was active at the moment of phone call start.
What is the problem? Is it possible to post event to session that is not last but ended less than 4 hours as expected by "Queue Time" behaviour? Maybe I need to specify some additional parameter?