We have apache 2.4 running on a Windows Server 2012, everything works fine except one strange bug:
The server stops serving any pages to users after someone visits any page via Chrome for Android. The visitor on the Android device (only when using Chrome) gets an "connection reset" error, but all users after that are getting blank loading pages until Apache gets restarted. If an user is loading a page on any other device during a restart, the page finishes loading immediately.
It seems that i can't find anything specific in the Apache or CF errorlogs. The only error i'm able to find is in the coldfusion-out.log:
Apr 15, 2016 13:34:43 PM Error [ajp-nio-8016-exec-15] - The request has exceeded the allowable time limit Tag: cfhttp The specific sequence of files included or processed is: C:\projekte\removed\So-funktioniert-es-6.html, line: 98
It does mention a specific file here, but it happens no matter what file or page you try to open. It's a really strange bug and we can't find any solution to it, nor anyone else with the same problem. The server isn't overloaded at all.
Hopefully i was specific enough for someone to point us in the right direction.
The error The request has exceeded the allowable time limit Tag itself says what's wrong.
The above error means your page has taken too long to finish
processing, so ColdFusion has ended the process in order to free up the server.
If you have access to the administrator, you can increase the timeout period
server-wide in the Settings page (Timeout requests after n seconds) - if you
just want to increase the timeout period for that particular page, you can tack
on requestTimeout=x (where x is the number of seconds before the page times
out) to the url as below:
http://your_url?requestTimeout=desired_time_in_seconds
Alternatively you can use the tag <cfsetting requestTimeOut = "desired_time_in_seconds"> within your
code to overide the default setting.
Edit: If it is occuring only on Chrome then there must be something that's breaking your request. Most probably Javascript, Ajax, Jquery. But try the above method first.
Related
The way I've currently set it up,
Each device makes an API call to my server with a unique ID it generates on first launch as POST data.
The API call renews the timestamp of that ID.
The devices make this call every 20 minutes. Hence every 20 minutes, they update the server for with the current time as way of indicating when last they were active on the device.
Then to view the active devices, I've got a web page, which shows me how many devices have had the app running within the last 21 minutes.
But I feel this is a bit primitive, there has to be a more efficient way, even for a hybrid cordova app. I don't think Whatsapp literally checks the network state of devices every millisecond.
If you know any cordova plugin that can help me acheive this, I would be more than grateful that you shared.
Google Analytics (using iOS SDK version 3.14 and it's built in sessions tracking) is reporting a significant percentage of app sessions as 1 second.
Maybe users are launching an app to view a page and (effectively) then instantly leaving the app, but that seems unlikely (that it should continue as the top use case. You think such users would stop using or uninstall.)
Initially I suspected this was related to "background fetch" but when I look at a prior incarnation of the application (that did not have background fetch enabled or used) I still see these (seemingly) bogus sessions also. That application (pre iOS9) had no universal links.
The (obvious) reason I don't want to see these sessions (especially if from automated action not user action) is it removes all value of "user behavior"; i.e. loyalty, recency and skews "average session length". These are the main reasons I want to use GA, i.e. to see if folks are using it more/valuing it more.
My questions:
What might these sessions be caused by? Are they bogus?
If bogus, how can I stop them?
Can I ensure new "background fetch" code doesn't somehow trigger them?
Some things I've considered / looked into:
I am seeing a similarly large set of "short sessions" on an Android application (this application's peer) and again with extremely high numbers. I've been wondering if this was a result of a web searches & site links, with those site links automatically loading the app, and the a (very) quick user "move on". (Universal linking is something the new iOS application is working towards, but doesn't see much of yet.) Given it is not that on iOS I am starting to doubt that it is that on Android.
There is a "optOut" option on GA. That feels like a sledgehammer solution to this walnut problem. It is also a persistent setting, which feels risky to use for a transient situation. I could attempt to toggle it at applicationDidEnterBackground / applicationDidBecomeActive (and will if it is deemed the solution) but worry it could have negative side-effects.
One can have multiple trackers. I am planning to attempt one for human foreground activity and one for background operations (which might allow time /event tracking when in background, w/o impacting human user tracking numbers. That said, I don't know / believe this is the cause of the bogus sessions. )
One can manage sessions manually and also customize the sessions interval timeout, but I don't see why this application should need any custom behavior. It is a normal application.
The application isn't reporting crash totals to match these numbers; it is a generally well liked 4/5 star app w/ few crashes.
Google Analytics measures duration as the time between interactions.
This means that in order to be able to measure duration, Google Analytics needs a minimum of two interactions to measure between. But they still need to collect data on one-interaction Sessions, and from the reporting perspective, every session starts the same - with an interaction. It's just that some don't go any further. To account for this, Google Analytics keeps a running total of Session duration.
When a user first interacts, that total is set to 0.
31 seconds later, they interact again. That total is updated to 31 seconds.
10 seconds later, they interact a third time. Total is now 41 seconds.
35 seconds later, they quit. This is not measurable, and hence not an interaction. Google Analytics waits faithfully for 30 minutes, before deciding that they aren't coming back.
Your total Session Duration is recorded as 41 seconds, as that was the last point at which you checked in. There's no way of knowing that you stuck around an extra 35 seconds.
This isn't an issue if you looked at 4 or 5 pages, but if you had only looked at 1 page, we would have been left with a Session Duration of 0. This is what happens with every 'Bounce'; every Session with only one interaction is measured '0' seconds long.
Throw into that a handful of people who interacted 8 or 9 seconds later, and you have an average of 1 second for the '0 - 10' category.
Turns out the problem was inside the Google Analytics SDK. A new version has been posted:
[Google Analytics SDK issue with short sessions][1]
I'm sending requests from my android phone one at a time as fast as possible to my server, and then graphing the time (x axis) vs hit number (starting at 0). After running this on Andrid for about 10 minutes, I get a graph like this:
The flat parts are unexpected. This signifies that every 3 minutes or so, there's a 1 minute lag that happens. Why might this be happening?
A few things I've noticed:
It doesn't matter if the screen is on or off
My server is not the problem. During the long pauses, I'm able to hit the endpoint on my server separately from android.
Both POST requests and requests over websockets have the same problem
It is possible the problem is my android data connection; I'm not sure how to remove this as a possible variable. It would be odd that the data connection would do this.
I have a broadcast receiver watching the wifi state and sending an http request to me server when it becomes enabled. The problem that I have is that when I run the code under debugger it works just fine, but when I run the same code without a debugger, it throws an exception.
The exception indicates that the failure is actually the DNS resolution failure - it fails to resolve the DNS name.
I decided that even though the system fired the 'enabled' event, the DNS resolver is not fully initialized yet and added a 10sec delay before the attempt to send my request and this resolved the issue, but I am really uncomfortable with this solution. Even though in my case it does not really matter, 10 sec seems too long. A bigger question will 10 sec be enough on all platforms?
Another solution would be to intercept this particular exception and try again. The question is - how many retries?
My question is - what's the best way to wait until the DNS resolver is fully initialized? Is there an event or a notification I can subscribe to?
I have an android app that I'm building and it's based on a web app that lets users login and reserve a book (think library). Because you are able to reserve books it needs to have a valid session (cookie to be exact)
Here is my issue - how can I work with multitasking when I have this 20 minute constraint?
Do I keep a timer running the entire time the app is up (in the Application global object) -then on resume verify this timer is under the 20 min window and if so assume cookie is good - else ask them to login again.
Or do I blow away the activities loaded (in my app) on resume and start the app over each time the user clicks the icon from the home screen
Or something else? I simply avoided this in my iPhone version because I don't support multitasking currently (maybe I will if the android solution fits)
Thank you in advance!
Normally people handle this problem by assuming any cookie they have is valid and letting the server tell them if they need to login again. The client should have very little (read: none, if possible) intelligence about this aspect which they cannot control.
You have several options, and which one's the best will depend on the app specifics
You can set up a timer to log out after 20 mins, either as part of your Application or as a part of your Activity (although in the latter approach, it will be lost if the activity is restarted).
Can set an Alarm to fire an Intent to show the login screen after 20 min (if you want to force a re-log in) or to set a flag LOGGED_IN=false if not.
You can set a long field in your Application object and query it during onDraw(), or while fetching a new page, or whenever you deem fit: if it's past the 20 min point, logout.
If the app will be fetching the book from a server one page at a time or similar, then I would add a time token to the POST request and let the server decide whether to return the page or to send a 401 error. You would then handle the error by showing the log in screen and reposting if log in is successful