Unsolved
This post is more than 5 years old
1 Rookie
•
56 Posts
0
2104
March 19th, 2010 09:00
Recommendation For Create Object Failures
Occasionally we get timeouts on some of our calls to Atmos. Timeouts as defined in our libcurl implementation basically means no data recieved at all on our connection in a specific (configurable) amount of time. Our default is 60 seconds.
Sometimes those are on the Create Object call. And there's the rub. If we abort the call by closing the connection, we don't get an object ID. The software can't wait indefinitely. Can that object still be created? If so, there is an "orphaned" object out there, for lack of a better term. It doesn't have an data attached to it at this point, but will I still get charged for it?
We're also debating not adding metadata to the object until after the object is created successfully. Right now we add metadata in the create object call to avoid the overhead of another call. But we're pretty sure our searches (done strictly for DR purposes only) are returning these zero length objects, and thats not particularily desirable.
Is there a recommendation from EMC for how we should handle this?
What would be a maximum recommended timeout to tolerate?
Open to suggestions to rework our implementation...
0 events found
JasonCwik
281 Posts
0
April 16th, 2010 08:00
Hi Adam,
A few things you can try:
1) If you use the namespace interface you can put a path and/or filename on your object at create time. That way, you can set your own identifier on it and check to see if it exists after a failure.
2) You could create an empty object in the first call and then update it with content in a 2nd call.
3) On your create call, add a listable tag called "in_process" or something. After a successful upload, delete the tag from the object to indicate it is complete. You can then periodically list all objects tagged "in_process" and clean them up.