[
https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944865#comment-13944865
]
Nick North commented on COUCHDB-1986:
-------------------------------------
Sorry - I was not very clear. The problem was caused by me when adding my new
code, and I fixed it before committing, so there's not much to point at now.
But, in essence, the problem was with couch_doc:mp_parse_atts - the body_end
clause needed to change from:
mp_parse_atts(body_end) ->
fun mp_parse_atts/1.
to:
mp_parse_atts(body_end) ->
receive {get_bytes, Ref, From} ->
From ! {body_end, Ref, <<>>}
end,
fun mp_parse_atts/1.
to push the end-of-body information through. The change is necessary because,
when attachment lengths become optional, you have to change from "parse the
number of bytes specified as the attachment length" to "parse until you hit the
end of the attachment, and then notify everyone that you have finished". The
interesting thing is that the bad code sometimes worked, and sometimes didn't,
depending on whether other circumstances caused a hung process to be killed (I
think) - the actual document loading work had all been done, but the parser had
not cleared up after itself, so kept a socket alive somewhere until the process
died.
That's makes me wonder if something similar is happening here - the replication
worked has finished, but the system is waiting for a "finished parsing"
indicator that never turns up. If the same sort of thing is happening with the
replicator, it would be around the couch_replicator_api_wrap:mp_parse_mixed/1
function and the process it's communicating with. but that's as far as I have
got so far.
> 04-replication-large-atts.t times out
> -------------------------------------
>
> Key: COUCHDB-1986
> URL: https://issues.apache.org/jira/browse/COUCHDB-1986
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Affects Versions: 1.5.0
> Reporter: Jan Lehnardt
>
> 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier
> or later, but it times out eventually, regardless of the timeout. I tried
> doubling and such.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
