[JAVA-1771] Validating a GridFS file can fail as mismatch if using None write concern. Created: 19/Apr/15  Updated: 11/Sep/19  Resolved: 20/Apr/15

Status: Closed
Project: Java Driver
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Paul Rutledge [X] Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible

 Description   

Most (all?) GridFS drivers offer some sort of validation where they compare the driver's computed MD5 with the MD5 returned by the filemd5 mongodb command. I've found that sometimes this validation can report a md5 mismatch (indicating corrupt contents) if done immediately after the write operation without ACKNOWLEDGED write concern or higher.

I understand that this is in a sense due to the nature of what the write concern means, however I think an MD5 mismatch is a vague / misleading type of exception to throw in this case. Is there any way to indicate to the application / user that the reason the MD5 does not match due to the write being incomplete?

Why is it possible to call filemd5 before writes are complete since it doesn't really mean anything useful?

I also understand that the default write concern under the 3+ drivers won't encounter this issue, but perhaps there is something that can be done to improve the error reporting here?

See my original question and answer in this stackoverflow:
http://stackoverflow.com/questions/29101248/what-causes-a-mongodb-gridfs-md5-hash-mismatch/

I wasn't sure whether to file this as a core bug (being able to call filemd5 commands on incomplete data and receive a seemingly valid response) or a driver improvement for throwing more meaningful exceptions in this case. I think a reasonable solution could also be to just provide documentation on this (either for the server or drivers, or both).



 Comments   
Comment by Paul Rutledge [X] [ 20/Apr/15 ]

I wasn't so much looking for an answer or saying that the existing behavior is wrong, but I thought there may be opportunities for improvement around this as it took me a couple of hours of testing to determine the cause. I don't see a reason why the filemd5 command shouldn't throw an exception if a write is still underway, but perhaps this information is unavailable and so it is not reasonable to address? Does it make sense to document this behavior? If you think the existing stackoverflow question is enough to help others who may encounter this then I'm fine with leaving it closed.

Comment by Jeffrey Yemin [ 20/Apr/15 ]

I moved this to the JAVA project as it's not a core server issue that you're having.

It looks like you answered the question on SO, so I'm going to close this, but please re-open if you think it necessary.

Generated at Thu Feb 08 08:55:27 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.