[CSHARP-1163] FileSize exception in db.stats() / DatabaseStatsResult when WiredTiger in use Created: 14/Jan/15  Updated: 06/Apr/15  Resolved: 04/Apr/15

Status: Closed
Project: C# Driver
Component/s: Error Handling
Affects Version/s: 1.10
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Chad Kreimendahl Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

windows 8.1 .net 4.5.2 1.10-rc1



 Description   

When using wiredTiger storage engine, all stats return properly except for FileSize:

dbsr
{MongoDB.Driver.DatabaseStatsResult}
    base: {MongoDB.Driver.DatabaseStatsResult}
    AverageObjectSize: 1874.7385493229142
    CollectionCount: 246
    DataSize: 1053679929
    ExtentCount: 0
    FileSize: 'dbsr.FileSize' threw an exception of type 'System.Collections.Generic.KeyNotFoundException'
    IndexCount: 2794
    IndexSize: 279265280
    ObjectCount: 562041
    StorageSize: 324399104



 Comments   
Comment by Craig Wilson [ 06/Apr/15 ]

You're right. We should have addressed this when we had the chance. My apologies for letting it slip through. Unfortunately, now that we've released 2.0.0 final, we can't do this anymore.

In this case, since you know FileSize is simply unreliable, can you not just stop using it? Not calling it seems like it would solve the problem? Alternatively, perhaps since you are trying to store these historically, you should stop using the provided GetStats method and, instead, run the command

{dbstats: 1}

manually and let it come back as a BsonDocument. We don't provide a GetStats() method in the new API, so this is how it would be done if/when you migrate.

Again, my apologies for not addressing this in time.
Craig

Comment by Chad Kreimendahl [ 06/Apr/15 ]

Given that our efforts to update to 2.0 gave us about a dozen breaking changes (all of our custom dictionary serialiizers), I'm curious why it couldn't be a breaking change to a nullable int in a 2.0? It seems to fit much better.

Given that any attempt to re-serialize the db.status() results in an exception... it becomes painful to do something like store your db stats historically in another collection. You basically have to write your own serializer for something that should just be null[able]

Comment by Craig Wilson [ 06/Apr/15 ]

An exception is the most logical result here. If we don't have access to the actual value (because the server changed the response), then not throwing an exception would provide you with an invalid value. Changing the type to a nullable long would be a breaking change, so we can't do that. An exception is the only reasonable option left.

Craig

Comment by Chad Kreimendahl [ 06/Apr/15 ]

At least make it not throw an exception?

Comment by Chad Kreimendahl [ 21/Jan/15 ]

It appears that fileSize may be going away in general. While mmapv1 will have it, the others will not require it, as it can be expensive.

I've also found that storageSize + indexSize seems to be almost exactly the sizeOnDisk equivilent (which may work). Of course, it may just be better to use only the ones that are common among all.

Comment by Chad Kreimendahl [ 14/Jan/15 ]

I'm just getting into the collection stats stuff now, too, and will have a bug for that one as well.

It looks like for database stats that, at least in the shell, it's substantially smaller set of data. I'd imagine that's the same data you get. For collection stats, it appears there's a massive new set of info that it shares.... specifically about how it's doing indexes in WT.

I think if they aren't reporting FileSize, that possibly a nullable value there would be best? I'd hate to assign it to dataSize and be wrong.

For collection stats, I think just getting the GetTotalDataSize and GetTotalStorageSize working again would be good enough.

Comment by Craig Wilson [ 14/Jan/15 ]

Thanks Chad.

Yeah, WT has some different output and I'm not sure about what it all means yet. We are still deciding how exactly to handle some of these changes. Any thoughts you have would be welcome.

Craig

Comment by Chad Kreimendahl [ 14/Jan/15 ]

I should say... the output from db.stats() on wiredTiger doesn't have a "fileSize". I'm wondering if this is a SERVER issue, not C#... and second, I'm wondering if WT doesn't report FileSize, if DataSize might be identical?

Generated at Wed Feb 07 21:38:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.