This post is more than 5 years old
4 Posts
0
1687
FP_BLOBIDMISMATCH_ERR sometimes happen, sometimes not.
Hi,
I'm working on a feature to backup and restore archive from centera. I have a question that I'm using centera test server and sometimes I faced an FP_BLOBIDMISMATCH_ERR exception. I know it's file corruption but I'm not sure that why it happens.
The possibility is 60% (throws exception) / 40% (restore successfully). Pushing files to centera test server always successful with returned cdf address, right after I got cdf address, I used it to restore and application throw exception to me.
Do you have any clue about that?
Thanks.
mfh2
208 Posts
0
July 7th, 2015 14:00
Hi Zoom -
Something definitely flaky/bad is going on.
Around line 460 in the failure log you are opening a CDF (83J6FM07TAUD1eCDPPFFFMT6DUEHqRTnKQVA9F1dmJcsFWcJBWbnD) which returns a BLOBID_MISMATCH exception. This really should never happen (blobid mismatch when opening CDF) and is not related to your code at all.
I can see from the format of these clipIDs that you are talking to an Atmos backend; try your test against an actual Centera.
Best Regards,
Mike Horgan
mfh2
208 Posts
0
July 7th, 2015 04:00
Does this behavior happen on a single thread? If so, try recording an SDK log to get a detailed view of the operations and exceptions. Also, try reading the content with JCAScript to see if it consistently fails as well.
Good luck,
Mike Horgan
ZOOMInt
4 Posts
0
July 7th, 2015 10:00
Hi Mike,
I'm using XAM and the SDK is provided from customer (lib32.tar.gz), so I don't really know how to log this.
The result return base64 string, I decode and take content address from decoded string. Below is an example:
From base64:
AAAEcwA9kfFCMEYwUzVTREVLRzIwZTBMUUtDUUMxRjA3NExIcGhUbktRVkE5RjFkY3daUUZXY0I5NHdaOQ==
To content address:
B0F0S5SDEKG20e0LQKCQC1F074LHphTnKQVA9F1dcwZQFWcB94wZ9
JCASScript return the same error as in my application:
Is this because of centera test server? because sometimes I can upload and restore from centera successfully but sometimes not. That's really troublesome
. I don't know should I trust test server 
mfh2
208 Posts
0
July 7th, 2015 11:00
That's a twisty situation yo have there
SDK log is simple: just set FP_LOGPATH env var to be the full path to a target log file. For example 'set FP_LOGPATH=\tmp\sdk.log'.
If you get a log and you want to upload it here we can have a look.
Best Regards,
Mike Horgan
ZOOMInt
4 Posts
0
July 7th, 2015 12:00
Hi Mike,
I have attached a log file, please help me to take a look.
Thank a lot for helping me
2 Attachments
centera_success.log
centera.log
ZOOMInt
4 Posts
0
July 8th, 2015 00:00
Hi Mike,
Thank you, it seems you are right. I changed server to Centera Cluster 4 and problem is gone. I ran 4 times straight and faced no problem!.
My question is what's different between Atmos and Centera?
Regards,
Tran Cuong Truc.
mfh2
208 Posts
0
July 8th, 2015 02:00
Hello Tran -
Glad to hear that fixed your problem. The CAS implementation on Atmos is a translation layer built on top of the native REST protocol. I believe its use has been deprecated in favor of ECS's CAS implementation for new deployments; you should test your code against the public ECS cluster(s) as well.
The other thing you should consider is that EMC is no longer actively supporting XAM (as announced in 2012, see Open Questions in regard to "change to XAM SDK support") and XAM software will not be eligible for official support for ECS-CAS customers. Paul McKeown put together a white paper around converting XAM apps to use the Centera SDK which you should review.
Best Regards,
Mike Horgan