On 27/09/2009 16:34, Stephan Knauss wrote: > Hi, > > API rejects my clients for quite a while now.
Presumably since about 8 days now, since that is the time for which TRAPI (tiled read-only API) has been down. Since TRAPI is the main data source for t...@h, it going down unfortunately always has big knock-on effects both on t...@h and other parts of OSM. There are two fallback alternatives, the main API and XAPI. However, neither of those is anywhere close to as performant as TRAPI with respect to the type of requests t...@h does and so has no chance on being able to cope with the load t...@h puts on them. So until TRAPI catches up again with updates and serves current data, I suspect there is not much t...@h can do. In fact, I would even vote for removing XAPI from the list of fallback sources for t...@h. It can't cope with t...@h request, and I suspect overall it doesn't make much difference to t...@h. On the other hand t...@h seems to take down XAPI and prevents all other users to use XAPI so has a very negative effect on them. So the question is what can we do to get TRAPI up and running again? Last I heard was that from the two servers "running", one was in the process of rebuilding its db for the last two weeks and the other can't keep up with updating its db with all the imports and automated fixups currently going on. I think neither of them are particularly fast servers though, so perhaps someone else can provide a faster server? It does need a fair amount of bandwidth though with on the order of 5 - 10 Mbit/s running to 500Gb - 1Tb per month, although that is uncompressed xml, so probably could be cut down a bit. I first thought this is > something to reduce the load on the API. Well, yes and no. As said above, TRAPI is down and thus rejects all requests straight away. XAPI times out after a while and may or may not get some random set of requests processed and the main API has a proper load management to ensure that a constant stream of requests gets processed, but as it is by far not enough, most requests get queued and potentially timeout before the API has a chance to dequeue and process them. But I see other clients > uploading data. Is it just bad luck with my clients to never get data or > is it something with the UserAgent filtering on API? What is the exact > string it matches? also the OS-field? I don't know what the exact filtering is, but I am pretty sure it is not the OS-field. It is only filtering for t...@h to ensure that both t...@h and other clients like JOSM are separated and don't interfere with each other and both get some resource even under overload. So please don't fiddle with any of these settings, as that will only lead to a worse experience for everyone! My guess would be the reason for some others to still upload is either "better luck", or more likely that they are running their own trapi or roma server locally for their clients. Kai > > Stephan > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
