BUG in new OSIS model??
Hi,
Last week I did an EV upgrade from EV2007SP3 to EV8.0 at one of my customers.
Upgrade went fine without any issues. After the upgrade I also added file server archiving (I postponed this functionality because of the new OSIS modle in EV8.0
When I tried to archive (as a first test) two identical files in two different folders (pdf files, same name, same size, same date, ...) I discovered that the files were two times archived into the file store partition.
So, for the two identical files I have 2 DVS files in the store (which is normal) but I also have 2 dvssp and 2 dvscc files.
AM I correct to state that this is not normal for the new OSIS model?
I would expect to have 2 dvs files, but only 1 dvssp and 1 dvscc file (as shared system parts), not?
In the meantime I also tried this on another EV8 test system, also here the same unlogical result.
Is there a bug in the new OSIS??
Greetz,
Rudy
Comments
Hi Rudy
I have the same result here.. when the task runs, it saves the identical files twice as you reported.
When I run the task again and it has to archive the "same" file again (even renamed), it does sharing.
So it seems the task does no sharing in the "same run".
Hi,
you are correct in that it should not normally occur. ie it should sis.
My guess is that when the first file was archiving the 2nd instance was also being archived just around the same time and so we couldn't read the existing item to check the finger print etc. Which would explain why the 2nd time a run occurred it was fine.
To test you can either do two things.
One get a dtrace and check yourself or.
In the first folder put the pdf, in the second folder put plently of other files and the pdf. That way the chances are that by the time the 2nd thread is dealing with the pdf, the first one has finished with it and so will share... hopefully... Or another way is to put two differnt copies of the file into the same folder(I'm guessing tha that the same file but different name will sis but I could have that wrong)
Mike
Mike Bilsborough
Director,Enterprise Vault Engineering Support
Hi Guys,
Many thanks for your replies and ideas!
Doing some additional tests, I think I found an explanation for the issue.
As mike already mentioned it appears to be the speed of our test that caused the archiving task to loose the OSIS for the test files. I did some additional tests and the OSIS seems to work fine as long as identical files are not archived 'strictly together' in the archive task (situation we had in our test).
In 'normal' circumstances I don't think this situation will occur often.
The first test only had to archive two identical files at the same time. So, I think that in this case EV is also building up its fingerprint db at the same time for the two files. If the fingerprint of the first file is not finished, while building the fingerprint of the second file it appears that EV hase no fingerprint references yet and archives the files twice.
Am I correct, here ?
PS.
If I look at this in a more critical way, I should say: should be debugged because there seems to be or should be identical fingerprints now in the Fingerprint database.
... which is a little bit odd for a "fingerprint" database, not? ...
Greetz,
Rudy
Fingerprint collisions - where two items that are different but happen to generate the same fingerprint - are possible albeit rather unlikely in normal situations, however EV is able to handle the situation. What happens here is this:
-Both files generate the same fingerprint, and do a lookup against the fingerprint record to see if there is a match.
-There are no corresponding entries, so the lookup returns a NULL and an INSERT is performed.
-One of the threads/processors will complete the INSERT first. The other INSERT will then notice that the fingerprint record already exists, and will automatically INSERT another record that has a different value for the UniqueId column in the fingerprint db MemberTable. So the fingerprint itself is the same but the UniqueId has been incremented.
-Further attempts to SIS against a third item that is the same as the first two will succeed in finding an existing fingerprint record and will SIS as expected, probably with the first record rather than the ‘collision’ record.
As you say, if you consider it doesn’t take very long to fingerprint an item and insert a record, when you’re archiving “normally” rather than attempting to test OSIS with only 2 items the chances of this happening “in the real world” are rather slim. It can definitely be concerning when testing to notice this 'unexpected; behaviour!
Chris
Would you like to reply?
Login or Register to post your comment.