Okay, now I've confirmed the HTTP client is sending the POST more than
once. Perhaps it is a the TCP layer resending packets? Curiouser and
curiouser....
On Jul 15, 2008, at 4:46 PM, Damien Katz wrote:
Okay, so I went ahead and did a little debugging. For reasons
unknown, mochiweb is getting a network error, causing us to crash.
Then it appears mochiweb attempts the same request again. This is
fine for GET PUT and DELETE, they'll error out if attempted twice,
but it also does it for POST during the creation of new documents.
This it would seem is the source of duplicate documents some people
see?
On Jul 15, 2008, at 2:03 PM, Damien Katz wrote:
I'm a bit worried about mochiweb right now. It appears that
somehow, perhaps via a timing bug, mochiweb can get into a weird
state and start returning the wrong response to a http request. It
seems sometimes you get the result from a previous request, instead
of the current request. This can be any type of request it seems,
GET PUT or POST. We see the problem consistently when running the
tests from Safari, some people see it from Firefox too. The current
theory is that Safari is faster and causes the timing bug more
consistently than firefox.
This is a very bad thing. If our network interface doesn't give
back correct results, then how can we call ourselves a database? If
necessary, we'll have to revert back to the old inets httpd
library. It may have been quirky, slow and under-documentend, but
it was pretty solid once working. I hope that's not necessary.
Right now I think this bug is the highest priority and anyone is
welcome to attack it. https://issues.apache.org/jira/browse/COUCHDB-95
I don't have time this week to debug it, but if its still a problem
by next week I'll start debugging and poking around more thoroughly
inside mochiweb.
Any input or help is welcomed.
-Damien
