Just configured my first iPhone on an 8.5.1 server with Traveler 8.5.1. It has only been a couple of hours, but it appeared to be working okay. However, in the Web Server logs I’m seeing periodic 409 CONFLICT errors such as:
=========================================
User Agent: Apple-iPhone/704.11
Cookie:
Request: POST /servlet/traveler/Microsoft-Server-ActiveSync?User=REDACTED&DeviceId=Appl88926N4U3NR&DeviceType=iPhone&Cmd=Ping HTTP/1.1
Status: 409 CONFLICT (The request could not be completed due to a conflict with the current state of the resource)
These will be accompanied by a series of 200 OK status requests that were completed successfully. Any ideas what the “409 CONFLICT” errors mean and why?
Sorry. I realize the silence is most likely because a) nobody knows, b) nobody cares, c) nobody else is having the issue.
Seems important to a highly anticipated new function in Traveler 8.5.1, the support of the iPhone.
Not sure if functionality is being affected by this because the user is an executive who wants his iPhone but assumes that all high-tech devices act weird. So I’m not getting much feedback so long as emails appears to be flowing normally (in his opinion).
More:
The web server error occurs nearly every time the iPhone is touched or touches the server via Traveler. The error is similar to another command that always completes successfully. Compare:
FYI - not ignoring and do care - Limitted staff so only review the forums about 3 times a week.
Anyway - 409 means a sync was initiated, but the device connected and initiated a new sync before the last one finished. It is fairly common scenario and generally does not hurt anything. If high percent of syncs end in 409 then may want to troubleshoot further to improve overall performance and user experience. See this Info Center topic which has an example on show stat command that can take a look at percentage of syncs that end in 409 vs 200.
The “409 CONFLICT” error is happening on ping commands, not sync. Typical request is:
POST /servlet/traveler/Microsoft-Server-ActiveSync?User=redacted&DeviceId=Appl88926N4U3NR&DeviceType=iPhone&Cmd=Ping HTTP/1.1
Running a couple of searches in the web server log over a few days of data gives 1,763 PING requests. 1,095 of them were successful with 200 OK codes and 668 of them threw 409 CONFLICT.
Even more interesting is the response time. I’m showing PING commands with the response time ranging from 0 ms to 303,110 ms. That last one is five minutes.
The 300,000 ms is not an anomaly. The overwhelming majority of the response times are roughly 80,000 ms to 300,000 ms with an approx average of 200,000 ms.
Oddly, successful responses (“200 OK”) don’t appear to take any less time than the “409 CONFLICT” responses.
SYNC commands take dramatically less time, usually just 75 ms to 300 ms. And, out of 10,000+ SYNC requests in the web server log, only one did not return a 200 OK. So there is no problem happening with the SYNC.
What are the PING commands doing? Why would the responses be so unreliable and take so long? Is there at timeout value at 5 minutes that it is hitting, and where might that setting be stored. Lastly, does it matter?
You can change the Servlet console handler level to be less than FINER if you don’t want to see these messages in the console (they are really debug type messages/details). The default is that you don’t see these, but you apparently wanted to see them which is fine.
The 409 is used differently for sync (any device) and ping (Apple only). Corey covered the sync part, so let me explain the ping part.
ActiveSync uses the “Ping” message for what Traveler calls “push” or “auto sync”.
The Ping messages are long running. The client opens that connection to the server and the server does not respond to that until it has changes that the device should sync OR a timeout is reach (5 min, 10 min, etc.). Thus, the times for these requests can be short or long depending on how much data you receive.
The Sync messages are NOT long running. The client wants to sync data and the server responds as soon as it can.
The Apple device tries to have only one HTTP request pending with the server at a time. That means that it is either using Ping or Sync at one time but not both.
So, here is a normal flow of what happens:
Device is up to date and sends Ping to the server.
Some time passes.
You receive a new mail on the server.
Server responds to the Ping message (200rc) to tell the device to sync.
Device sends Sync to the server.
Server responds to the Sync message (200rc) with the new mail.
Device is done syncing, so it sends a new Ping to the server.
The user sees that there is new mail on the Apple and opens Mail.
Whenever you open mail, the Mail application does a Sync.
Because Apple only maintains one HTTP connection to the server at a time, it has to abandon the pending Ping request and start a new request for Sync. The device closes the Ping and sends Sync to the server.
The server gets the Sync request.
The server does not get notified that the device has abandoned the Ping, so the server has both requests open at this point.
The server knows that the device only has one connection at a time, so the server knows the Ping request has been abandoned. To free up resources (a HTTP thread) on the server, the server closes the abandoned Ping. The server needs to return something to close it (although the device shouldn’t be there and shouldn’t actually receive the response), so it returns a 409 CONFLICT return code. We chose “conflict” because the it can be interpreted as a conflict between the 2 connections (Sync and Ping).
Server responds to the Sync message (200rc).
The device is done syncing, so it opens a new Ping request.
And so on and so forth.
The bottom line is that Ping requests will be long running and often (whenever there is a sync request) result in a 409 return code which is not a real problem. The 409 lets us know why the request as returned and whether or not it has real data in it (200) or not (409).
Excellent explanation, Robert. I don’t want to hide the 409 items from being logged, but now that I know how/why they are appearing, I can confidently ignore them.
Subject: Traveler causing HTTP Server: Waiting for session to finish
Hi,
We have recently installed Traveler and this issue stops us from restarting our http server. We get loads of the following error:
03/03/2010 02:25:00 PM HTTP Server: Waiting for session to finish: Session State [Processing Request] Session ID [6287] Thread ID [3716 (0xe84)] POST /servlet/traveler/Microsoft-Server-ActiveSync?User=michael%20brown&DeviceId=Appl880069LM3NP&DeviceType=iPhone&Cmd=Ping HTTP/1.1
Unfortunately this server runs our corporate website so cannot wait for all the threads to finish and we need to restart the Domino service to fix it.
Server spec is Lotus Notes Traveler 8.5.1.1 Build 201002041652 running on Lotus Domino server Release 8.5.1FP1. We are using Apple iPhones - 17 users.
Would appreciate if anyone has any ideas/solutions.
That was a GREAT explanation of what’s going on behind the scenes. Thanks so much! Wondering if I could ask a related question.
There are these two settings that are confusing me: Heartbeat Algorithm Max Interval and the Min. According to the docs, these are the settings that apply to Apple. What are the appropriate settings for maximum battery life on the devices? I realize that appropriate settings are different for every environment given that firewalls differ, but are there any guidelines? Meaning, if you set the Min Interval higher, does that help battery life on the devices?
