[CSHARP-1981] GridFSChunkException,Message:GridFS chunk 0 of file id 222448ab20170509181609bd is missing. Created: 09/May/17 Updated: 27/Oct/23 Resolved: 01/Jun/17 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | Error Handling, GridFS |
| Affects Version/s: | 2.4.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Blocker - P1 |
| Reporter: | Ummer Irshad | Assignee: | Robert Stam |
| Resolution: | Works as Designed | Votes: | 1 |
| Labels: | Bug, driver | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
OS:Windows Server 2008 R2 |
||
| Issue Links: |
|
||||||||
| Description |
|
We are running load test with MongoDB V3.2.12 and below mentioned error is thrown when reading the binary file from GridFS. I had raised a bug. Refer:https://jira.mongodb.org/browse/CSHARP-1970 and it is one of the target for 2.4.4.
Please assist. Thanks in advance. |
| Comments |
| Comment by suraj [ 19/Jun/18 ] | |||
|
hi Robert, We have tried with retry logic as Ummer Irshad is mentioned above , but recently while using MongoDB version 2.6.1 we have got the same issue "Type:GridFSChunkException,Message:GridFS chunk 0 of file id 001f7c182018061320020001 is missing", but only once. | |||
| Comment by Robert Stam [ 01/Jun/17 ] | |||
|
Closing this ticket as Works as Designed. Please reopen if you need to follow up any further. | |||
| Comment by Ummer Irshad [ 18/May/17 ] | |||
|
Thank you for providing necessary clarifications. Our current plan is to download the GridFS from secondary and go ahead with the retry logic. Can we keep this ticket open till we confirm everything is working fine? Thank you for your kind support and assistance. Irshad. | |||
| Comment by Robert Stam [ 17/May/17 ] | |||
|
Not that I know of. Can you download the GridFS files from the primary? That would avoid any replication issues. | |||
| Comment by Ummer Irshad [ 17/May/17 ] | |||
|
Is there any way to ensure replication has been completed in all secondaries? | |||
| Comment by Robert Stam [ 17/May/17 ] | |||
|
Each SecondaryPreferred read operation is a separate read operation and could be routed to different secondaries. So it is possible to read the metadata from one secondary which has replicated the GridFS file, and then get an error when trying to read the actual file from a different secondary which has not yet replicated the GridFS file. Any errors while updating the metadata would not be replication related, as all updates are routed to the primary. SecondaryPreferred does not take replication lag into account nor does it result in any reads being retried against the primary if there is an error reading from a secondary. | |||
| Comment by Ummer Irshad [ 17/May/17 ] | |||
|
As you said we are also thinking that this could be a replication issue. As I said in my previous comment, our application is first showing the list of jobs. For this, we are reading only metadata (not entire binary file). If replication is not completed, will driver returns the metadata? As a second step, our application requests the entire binary file. Here, we are getting exception. That too, not in all cases, but in few cases. Sometimes, driver is throwing GridFSFileNotFoundException exception when applications is trying to update the metadata after downloading the binary file. What could be the reason for this? I think this will not be a replication issue. Also, application is using "SecondaryPreferred". By any chance, driver will route to Primary DB, if secondary fails or replication is not happened fully? | |||
| Comment by Robert Stam [ 17/May/17 ] | |||
|
1. If we can identify a bug in the driver we will definitely fix it The two exceptions you mention are both indicative of the GridFS file data being incomplete. If you try to download a GridFS file from a secondary immediately after it was uploaded it might not yet have replicated to the secondaries, which could be an explanation for the exceptions you are seeing. Is that a possible scenario in your case? Or are these files that were uploaded a long time ago and should definitely have had time to replicate to all secondaries? | |||
| Comment by Ummer Irshad [ 17/May/17 ] | |||
|
Yes, we are using Secondary ReadPreference. Our application flow is as below: We are getting the problem in the second step mentioned above. That means when the application is requesting for a document(which DB/Driver already informed as available), we are getting either GridFSFileNotFoundException or GridFSChunkException. Please refer the comments above for more info about exceptions. Additional information: Our fix plan Request Thanks in advance. | |||
| Comment by Robert Stam [ 16/May/17 ] | |||
|
Are you by any chance using ReadPreference Secondary? I'm wondering if you are trying to read from secondaries before the data has fully replicated. | |||
| Comment by Ummer Irshad [ 10/May/17 ] | |||
|
One more information. Sometimes we are getting GridFSFileNotFoundException while getting binary file from DB. Below are the details of the same.
Thanks in advance, |