You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Erick Johnson <er...@junctionnetworks.com> on 2010/08/04 06:57:20 UTC
409 document conflict... but rev is correct
Hi all,
I have an automated job that runs hourly updating the documents in a single
couch database. The job has been running perfectly fine for about 2 months now.
However today, on updating one of the documents, couch consistently returns a 409
to the PUT. When doing a GET on the document I see that the _rev value sent
in the PUT is the most up to date revision.
From the book and the wiki I know of no other conditions in which a 409 is returned.
Could anyone offer me some advice on what else could be going on here?
Under what other conditions other than mismatched rev's does a 409 get returned?
I appreciate any help.
Thank you,
Erick Johnson
couchdb version:
$ /usr/local/couchdb/bin/couchdb -V
couchdb - Apache CouchDB 0.11.0
curl output:
>>> the GET >>>
$ curl -vvv http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
* About to connect() to 127.0.0.1 port 5984
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984
* Server auth using Basic with user 'user'
> GET /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: 127.0.0.1:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/0.11.0 (Erlang OTP/R13B)
< Etag: "2-2a29a1819ff496ab1dc3d19f79f1c029"
< Date: Wed, 04 Aug 2010 04:44:10 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 301
< Cache-Control: must-revalidate
{"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif
Keita - Mama"}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
>>> the PUT >>>
$ curl -vvv -XPUT http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 -d
'{"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif
Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}'
* About to connect() to 127.0.0.1 port 5984
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 5984
* Server auth using Basic with user 'user'
> PUT /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: 127.0.0.1:5984
> Accept: */*
> Content-Length: 255
> Content-Type: application/x-www-form-urlencoded
>
>
{"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif
Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}HTTP/1.1 409 Conflict
< Server: CouchDB/0.11.0 (Erlang OTP/R13B)
< Date: Wed, 04 Aug 2010 04:44:15 GMT
< Content-Type: text/plain;charset=utf-8
< Content-Length: 58
< Cache-Control: must-revalidate
{"error":"conflict","reason":"Document update conflict."}
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
--
Erick Johnson
1-800-801-3381 x7006
Junction Networks
sip:erick@junctionnetworks.com
xmpp:erick@junctionnetworks.com
Re: 409 document conflict... but rev is correct
Posted by J Chris Anderson <jc...@apache.org>.
On Aug 4, 2010, at 8:53 AM, Erick Johnson wrote:
> Hi Chris,
>
> Thanks for the reply. It's not proprietary data in the file, however
> before I ship out the file anywhere I'll have to check w/ some higher ups.
>
> But there's a new twist on this now... like I mentioned in the previous
> email, there is an hourly cron job updating about 80-90% of the records
> in the database. The error I'm writing about continued occurring for
> about 6 more hours after my initial email last night but has seemed to stop.
> Now the weird thing is this, the rev that was returned yesterday was
> rev 2-xxx. However a GET on the same document now returns rev 1005-xxxx,
> but the db rev limit is 1000.
>
> First, how can a document revision be higher than the rev limit of the database?
> Second, if the document is updated at most once/hour, how does the revision
> number jump from 2 to 1005 in less than 12 updates?
>
> It just seems like some weird corruption issue.
>
That actually sounds less like corruption than it did before, and more like something was backing up the http requests (so you had an update that proceeded to bump the rev, but was somehow not available for reading). It's still odd, and definitely worth looking more closely at.
As far as the rev num goes, with a limit of 1000 and rev 1005, that means the first 5 revs should now be stemmed (forgotten completely), nothing strange about that.
Chris
> >> DB info >>
>
> $ curl http://user:password@127.0.0.1:5984/stream
> {"db_name":"stream","doc_count":3171,"doc_del_count":4708,"update_seq":4254313,"purge_seq":0,"compact_running":false,"disk_size":209870954,"instance_start_time":"1280931315011866","disk_format_version":5}
>
> >> DB rev limit >>
>
> $ curl http://user:password@127.0.0.1:5984/stream/_revs_limit
> 1000
>
> >> Document w/ rev 1005-xxx >>
>
> $ curl http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
> {"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"1005-f02accd95cc3dab487a7674083c8a3dd","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama"}
>
> Thanks
>
> Erick
>
> On 8/4/10 10:30 AM, J Chris Anderson wrote:
>>
>> On Aug 3, 2010, at 9:57 PM, Erick Johnson wrote:
>>
>>> Hi all,
>>>
>>> I have an automated job that runs hourly updating the documents in a single
>>> couch database. The job has been running perfectly fine for about 2 months now.
>>> However today, on updating one of the documents, couch consistently returns a 409
>>> to the PUT. When doing a GET on the document I see that the _rev value sent
>>> in the PUT is the most up to date revision.
>>>
>>> From the book and the wiki I know of no other conditions in which a 409 is returned.
>>>
>>> Could anyone offer me some advice on what else could be going on here?
>>> Under what other conditions other than mismatched rev's does a 409 get returned?
>>>
>>
>> This seems odd. If you can make it reproducible, it may be a bug. If you can't make it reproducible, it could be a strange bug.
>>
>> Please don't compact or delete this database file. Is it possible to share the file with me? If it is non proprietary data we'd be happy to take a look at the file itself to make sure there aren't underlying issues.
>>
>> If you are comfortable doing so, please email me at jchris@apache.org and I'll arrange a way to receive the .couch file so we can debug over here.
>>
>> Thanks,
>> Chris
>>
>>> I appreciate any help.
>>>
>>> Thank you,
>>>
>>> Erick Johnson
>>>
>>> couchdb version:
>>>
>>> $ /usr/local/couchdb/bin/couchdb -V
>>> couchdb - Apache CouchDB 0.11.0
>>>
>>> curl output:
>>>
>>>>>> the GET>>>
>>>
>>> $ curl -vvv http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
>>> * About to connect() to 127.0.0.1 port 5984
>>> * Trying 127.0.0.1... connected
>>> * Connected to 127.0.0.1 (127.0.0.1) port 5984
>>> * Server auth using Basic with user 'user'
>>>> GET /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
>>>> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
>>>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>>>> Host: 127.0.0.1:5984
>>>> Accept: */*
>>>>
>>> < HTTP/1.1 200 OK
>>> < Server: CouchDB/0.11.0 (Erlang OTP/R13B)
>>> < Etag: "2-2a29a1819ff496ab1dc3d19f79f1c029"
>>> < Date: Wed, 04 Aug 2010 04:44:10 GMT
>>> < Content-Type: text/plain;charset=utf-8
>>> < Content-Length: 301
>>> < Cache-Control: must-revalidate
>>> {"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama"}
>>> * Connection #0 to host 127.0.0.1 left intact
>>> * Closing connection #0
>>>
>>>>>> the PUT>>>
>>>
>>> $ curl -vvv -XPUT http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 -d '{"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}'
>>> * About to connect() to 127.0.0.1 port 5984
>>> * Trying 127.0.0.1... connected
>>> * Connected to 127.0.0.1 (127.0.0.1) port 5984
>>> * Server auth using Basic with user 'user'
>>>> PUT /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
>>>> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
>>>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>>>> Host: 127.0.0.1:5984
>>>> Accept: */*
>>>> Content-Length: 255
>>>> Content-Type: application/x-www-form-urlencoded
>>>>
>>>> {"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}HTTP/1.1 409 Conflict
>>> < Server: CouchDB/0.11.0 (Erlang OTP/R13B)
>>> < Date: Wed, 04 Aug 2010 04:44:15 GMT
>>> < Content-Type: text/plain;charset=utf-8
>>> < Content-Length: 58
>>> < Cache-Control: must-revalidate
>>> {"error":"conflict","reason":"Document update conflict."}
>>> * Connection #0 to host 127.0.0.1 left intact
>>> * Closing connection #0
>>>
>>>
>>> --
>>> Erick Johnson
>>>
>>> 1-800-801-3381 x7006
>>> Junction Networks
>>> sip:erick@junctionnetworks.com
>>> xmpp:erick@junctionnetworks.com
>>
Re: 409 document conflict... but rev is correct
Posted by Erick Johnson <ej...@gmail.com>.
Hi Chris,
Thanks for the reply. It's not proprietary data in the file, however
before I ship out the file anywhere I'll have to check w/ some higher ups.
But there's a new twist on this now... like I mentioned in the previous
email, there is an hourly cron job updating about 80-90% of the records
in the database. The error I'm writing about continued occurring for
about 6 more hours after my initial email last night but has seemed to stop.
Now the weird thing is this, the rev that was returned yesterday was
rev 2-xxx. However a GET on the same document now returns rev 1005-xxxx,
but the db rev limit is 1000.
First, how can a document revision be higher than the rev limit of the database?
Second, if the document is updated at most once/hour, how does the revision
number jump from 2 to 1005 in less than 12 updates?
It just seems like some weird corruption issue.
>> DB info >>
$ curl http://user:password@127.0.0.1:5984/stream
{"db_name":"stream","doc_count":3171,"doc_del_count":4708,"update_seq":4254313,"purge_seq":0,"compact_running":false,"disk_size":209870954,"instance_start_time":"1280931315011866","disk_format_version":5}
>> DB rev limit >>
$ curl http://user:password@127.0.0.1:5984/stream/_revs_limit
1000
>> Document w/ rev 1005-xxx >>
$ curl http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
{"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"1005-f02accd95cc3dab487a7674083c8a3dd","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif
Keita - Mama"}
Thanks
Erick
On 8/4/10 10:30 AM, J Chris Anderson wrote:
>
> On Aug 3, 2010, at 9:57 PM, Erick Johnson wrote:
>
>> Hi all,
>>
>> I have an automated job that runs hourly updating the documents in a single
>> couch database. The job has been running perfectly fine for about 2 months now.
>> However today, on updating one of the documents, couch consistently returns a 409
>> to the PUT. When doing a GET on the document I see that the _rev value sent
>> in the PUT is the most up to date revision.
>>
>> From the book and the wiki I know of no other conditions in which a 409 is returned.
>>
>> Could anyone offer me some advice on what else could be going on here?
>> Under what other conditions other than mismatched rev's does a 409 get returned?
>>
>
> This seems odd. If you can make it reproducible, it may be a bug. If you can't make it reproducible, it could be a strange bug.
>
> Please don't compact or delete this database file. Is it possible to share the file with me? If it is non proprietary data we'd be happy to take a look at the file itself to make sure there aren't underlying issues.
>
> If you are comfortable doing so, please email me at jchris@apache.org and I'll arrange a way to receive the .couch file so we can debug over here.
>
> Thanks,
> Chris
>
>> I appreciate any help.
>>
>> Thank you,
>>
>> Erick Johnson
>>
>> couchdb version:
>>
>> $ /usr/local/couchdb/bin/couchdb -V
>> couchdb - Apache CouchDB 0.11.0
>>
>> curl output:
>>
>>>>> the GET>>>
>>
>> $ curl -vvv http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
>> * About to connect() to 127.0.0.1 port 5984
>> * Trying 127.0.0.1... connected
>> * Connected to 127.0.0.1 (127.0.0.1) port 5984
>> * Server auth using Basic with user 'user'
>>> GET /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
>>> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
>>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>>> Host: 127.0.0.1:5984
>>> Accept: */*
>>>
>> < HTTP/1.1 200 OK
>> < Server: CouchDB/0.11.0 (Erlang OTP/R13B)
>> < Etag: "2-2a29a1819ff496ab1dc3d19f79f1c029"
>> < Date: Wed, 04 Aug 2010 04:44:10 GMT
>> < Content-Type: text/plain;charset=utf-8
>> < Content-Length: 301
>> < Cache-Control: must-revalidate
>> {"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama"}
>> * Connection #0 to host 127.0.0.1 left intact
>> * Closing connection #0
>>
>>>>> the PUT>>>
>>
>> $ curl -vvv -XPUT http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 -d '{"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}'
>> * About to connect() to 127.0.0.1 port 5984
>> * Trying 127.0.0.1... connected
>> * Connected to 127.0.0.1 (127.0.0.1) port 5984
>> * Server auth using Basic with user 'user'
>>> PUT /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
>>> Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
>>> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
>>> Host: 127.0.0.1:5984
>>> Accept: */*
>>> Content-Length: 255
>>> Content-Type: application/x-www-form-urlencoded
>>>
>>> {"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}HTTP/1.1 409 Conflict
>> < Server: CouchDB/0.11.0 (Erlang OTP/R13B)
>> < Date: Wed, 04 Aug 2010 04:44:15 GMT
>> < Content-Type: text/plain;charset=utf-8
>> < Content-Length: 58
>> < Cache-Control: must-revalidate
>> {"error":"conflict","reason":"Document update conflict."}
>> * Connection #0 to host 127.0.0.1 left intact
>> * Closing connection #0
>>
>>
>> --
>> Erick Johnson
>>
>> 1-800-801-3381 x7006
>> Junction Networks
>> sip:erick@junctionnetworks.com
>> xmpp:erick@junctionnetworks.com
>
Re: 409 document conflict... but rev is correct
Posted by J Chris Anderson <jc...@apache.org>.
On Aug 3, 2010, at 9:57 PM, Erick Johnson wrote:
> Hi all,
>
> I have an automated job that runs hourly updating the documents in a single
> couch database. The job has been running perfectly fine for about 2 months now.
> However today, on updating one of the documents, couch consistently returns a 409
> to the PUT. When doing a GET on the document I see that the _rev value sent
> in the PUT is the most up to date revision.
>
> From the book and the wiki I know of no other conditions in which a 409 is returned.
>
> Could anyone offer me some advice on what else could be going on here?
> Under what other conditions other than mismatched rev's does a 409 get returned?
>
This seems odd. If you can make it reproducible, it may be a bug. If you can't make it reproducible, it could be a strange bug.
Please don't compact or delete this database file. Is it possible to share the file with me? If it is non proprietary data we'd be happy to take a look at the file itself to make sure there aren't underlying issues.
If you are comfortable doing so, please email me at jchris@apache.org and I'll arrange a way to receive the .couch file so we can debug over here.
Thanks,
Chris
> I appreciate any help.
>
> Thank you,
>
> Erick Johnson
>
> couchdb version:
>
> $ /usr/local/couchdb/bin/couchdb -V
> couchdb - Apache CouchDB 0.11.0
>
> curl output:
>
> >>> the GET >>>
>
> $ curl -vvv http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92
> * About to connect() to 127.0.0.1 port 5984
> * Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 5984
> * Server auth using Basic with user 'user'
> > GET /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
> > Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
> > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> > Host: 127.0.0.1:5984
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Server: CouchDB/0.11.0 (Erlang OTP/R13B)
> < Etag: "2-2a29a1819ff496ab1dc3d19f79f1c029"
> < Date: Wed, 04 Aug 2010 04:44:10 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 301
> < Cache-Control: must-revalidate
> {"_id":"ee0477b5d9323304cd2033521fae5fa6c185ca92","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029","server_name":"African","listen_url":"http://stream.wananchi.com:80/African","server_type":"audio/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama"}
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
>
> >>> the PUT >>>
>
> $ curl -vvv -XPUT http://user:password@127.0.0.1:5984/stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 -d '{"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}'
> * About to connect() to 127.0.0.1 port 5984
> * Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 5984
> * Server auth using Basic with user 'user'
> > PUT /stream/ee0477b5d9323304cd2033521fae5fa6c185ca92 HTTP/1.1
> > Authorization: Basic am5jdG5fY291Y2g6MGlqemE4N3Vha3pIMzhud0xLSA==
> > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> > Host: 127.0.0.1:5984
> > Accept: */*
> > Content-Length: 255
> > Content-Type: application/x-www-form-urlencoded
> >
> > {"server_name":"African","listen_url":"http:\/\/stream.wananchi.com:80\/African","server_type":"audio\/mpeg","bitrate":"128","channels":"0","samplerate":"0","genre":"african","current_song":"Salif Keita - Mama","_rev":"2-2a29a1819ff496ab1dc3d19f79f1c029"}HTTP/1.1 409 Conflict
> < Server: CouchDB/0.11.0 (Erlang OTP/R13B)
> < Date: Wed, 04 Aug 2010 04:44:15 GMT
> < Content-Type: text/plain;charset=utf-8
> < Content-Length: 58
> < Cache-Control: must-revalidate
> {"error":"conflict","reason":"Document update conflict."}
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
>
>
> --
> Erick Johnson
>
> 1-800-801-3381 x7006
> Junction Networks
> sip:erick@junctionnetworks.com
> xmpp:erick@junctionnetworks.com