And the confirm the first item, clearing the flag in a finally block makes it so the probe isn't tripped. So not a re-entrant call to send then.
-- Dean On 6/7/12 7:41 PM , "Dean Yu" <[email protected]> wrote: >The second point could be what's happening. > >During our investigations into this, I was noticing a lot of IOException: >Resource temporarily unavailable exceptions being raised when sending the >Unexport command. When I noticed this, I modified the TCP buffer sizes via >sysctl to see if we were hitting some limits. That didn't seem to to help, >but those exceptions could be causing what you're surmising. > > -- Dean > >On 6/7/12 6:31 PM , "Kohsuke Kawaguchi" <[email protected]> wrote: > >> >>So I kept thinking about the problem we looked at today in IRC, and here >>are few things that occurred to me. >> >>- The flag needs to be cleared in the finally block to ensure that it >> is accurate. Or else if the send() throws an exception, it can >> incorrectly raise an error when there actually is no lock >> re-entrance. http://pastebin.com/1CtSNpAX >> >>- If for some reason the sender raises an exception while writing to >> the stream, we can see a stream corruption without having the send() >> method re-entrance. >> >> >>So the detective work continues... >> >>-- >>Kohsuke Kawaguchi http://kohsuke.org/ >
