Zero Byte Attachment Problem Solved!

Tuesday 7th July, 2009

Ahh the joys of file operations on the Domino Server. Recently, I had to generate a file on the server and then attach it to a document which is available on the web. No biggy.. But Windoze "Delayed write" feature makes it a biggy, (I suppose it's as much of a feature as a stomach ulcer is a digestive enhancer).

Symptoms: You attach the file programmatically via LotusScript, no errors, but when the file is served over the browser no file is downloaed, HTTP Watch reports the file is serverd up with a HTTP response of 304, (un-modified file). Which this case has nothing to do with the source of the problem. You then check the file by detaching going into the Notes Client and the file is there, you can view the file from the notes client, all seems well.

Diagnosis: It's not obvious, but after a couple of days of using HTTP watch checking other server settings, you need to actually look at the attachment properties of the file in the document via the notes client. Notes will probably report it as a "0 byte (?)" file. The file is there, I can view it in the notes client, but when it goes through the browser it doesn't serve up the file. If you attach the same file via the Notes client and save it into the same RT field, there is no problem, the file is served up via the browser.

I think the Domino server looks at the file attachment details before sending it to the browser, and see's the attachment properties of the file is "0 bytes", which in turn appears to send back to the browser HTTP Response code 304, (not 200)...Hmmmm...

Basically, because of delayed-write in the O/S, the O/S has told Domino "Yep, the file is ready, here you go", but Domino is quick, quicker than quick, Lightning McQueen quick. The file has not been quite committed to disk yet, it's still flopping around like a fish out of water in the memory cache. Domino is attaching it, but only gets the file reference at that moment and not the entire file, as the save occurs a few milliseconds later, the entire file becomes available and get pushed into the RT Field. Thus you get a 0 byte file. Woot! What a great idea this Delayed write thingy. Just trick the 3rd party apps into thinking they have a file when it's not quite ready.

Attaching the same file via Windows XP has no issue because the file is already on your loca file system, and sent via your notes client over the network, which has nothing to do with delayed write on the Domino Server's O/S.

Solution : So, after a day or so of pfaffing about, the solution to these little horrors is correspondingly as simple, that you just feel humiliated. Just add a "sleep" function between the file create, and the embedObject method and hallellujah! You have salvation from developer hell. We shall walk without fear into the valley of the shadow of "Windows Server Evil", (no I'm not spiritual/religious, but I think there is a higher presence involved when dealing with these sort of problems) ! Many thanks to the Microsoft Windows server engineers who thought this stuff up, great for adding cost to development. Whatever medication you guys are on, you better lower the dosage, because it looks like it doesn't mix well with coke and pizza when you dreaming this stuff up on a Friday night to impress eachother infront of a whiteboard.

Also a gracious thanks to Gavin Bollard, (hat-tip), and his zen like "server wisdom" which pin pointed the problem to bring us this solution.

Comments [0]


Previous Document    Next Document