Middleware that provides libraries, GUI, and code generator to design multi-node (clustered) applications that are highly available, redundant, and scalable. Provides sub-second node and application fault detection and failover, and useful application libraries including distributed hash tables (checkpoint), event, logging, and communications. Implements SA-Forum APIs where applicable. Used anywhere reliability is a must -- like telecom, wireless, defense and enterprise computing. Download stable release with installer from: ftp.openclovis.com
A new API is required to efficiently read the checkpoint data from all sections without specifying section ids or iterating over sections with section iterator to read each section data in the checkpoint which is inefficient.
In short, the API should just read the section information (section id) and section data with section data size without specifying the section ids as an input vector.
The API should just pass the ckpt handle for the checkpoint and return the list of ClCkptIOVectorElementT along with number of io vectors that were read pertaining to the section data in 1 shot or 1 api.
SAFplus currently supports the SAF interfaces to read checkpoints through saCkptCheckpointRead that specifies a vector of section ids to read the section data.
It also allows a user to read the section data without knowing the section ids by using a section iterator to iterate over each section id before reading the checkpoint for each section using a combination of: saCkptSectionIterationInitialize -> saCkptSectionIterationNext -> saCkptCheckpointRead for each section id.
The first approach to read the checkpoint data though efficient as it specifies an IO vector of section ids to read the checkpoint data, still cannot be used for cases where section ids are not known in advance or cannot be specified.
The second approach though allows the user to read the section data from the checkpoint sections is a roundabout and inefficient approach based on a harebrained SAF specification.
It entails the user to iterate over each section before reading the data for that section from the server thereby entailing more than 1 server call to read sections.
We need a simple API that can read all the sections of a checkpoint in 1 api with 1 call to the ckpt master to read the same.
Something like this is desirable and nice to have as an add-on api on top of whatever SAF spec specifies which would be useful and efficient at the same time:
clCkptCheckpointReadSections
that can be used like this in a function to read all the sections in 1 shot:
static ClRcT testCkptRead(ClCkptHdlT ckpt)
{
ClCkptIOVectorElementT _pVecs = NULL;
ClUint32T numVecs = 0;
ClRcT rc = clCkptCheckpointReadSections(ckpt, &pVecs, &numVecs);
if(rc != CL_OK)
{
clLogError("CKPT", "READ", "Checkpoint read all sections returned [%#x]", rc);
return rc;
}
for(ClUint32T i = 0; i < numVecs; ++i)
{
ClCkptIOVectorElementT *pVec = pVecs + i;
// dump log identifier for the read data
clLogNotice("CKPT", "READ", "Read section [%._s] of size [%d] "
"with data at [%p]", pVec->sectionId.idLen, pVec->sectionId.id,
(ClUint32T)pVec->dataSize, (ClPtrT)pVec->dataBuffer);
// Now process the pVec->dataBuffer for the section of pVec->dataSize
// that is app. specific
}
// ok we are done processing. Time to tell the world we are done and no longer indispensable!
if(pVecs)
{
clCkptIOVectorFree(pVecs, numVecs);
clHeapFree(pVecs);
}
return CL_OK;
}
Keeping @CangTranOC in the loop who got this requirement from a customer.
A new API is required to efficiently read the checkpoint data from all sections without specifying section ids or iterating over sections with section iterator to read each section data in the checkpoint which is inefficient. In short, the API should just read the section information (section id) and section data with section data size without specifying the section ids as an input vector. The API should just pass the ckpt handle for the checkpoint and return the list of ClCkptIOVectorElementT along with number of io vectors that were read pertaining to the section data in 1 shot or 1 api.
SAFplus currently supports the SAF interfaces to read checkpoints through saCkptCheckpointRead that specifies a vector of section ids to read the section data.
It also allows a user to read the section data without knowing the section ids by using a section iterator to iterate over each section id before reading the checkpoint for each section using a combination of: saCkptSectionIterationInitialize -> saCkptSectionIterationNext -> saCkptCheckpointRead for each section id.
The first approach to read the checkpoint data though efficient as it specifies an IO vector of section ids to read the checkpoint data, still cannot be used for cases where section ids are not known in advance or cannot be specified.
The second approach though allows the user to read the section data from the checkpoint sections is a roundabout and inefficient approach based on a harebrained SAF specification. It entails the user to iterate over each section before reading the data for that section from the server thereby entailing more than 1 server call to read sections.
We need a simple API that can read all the sections of a checkpoint in 1 api with 1 call to the ckpt master to read the same.
Something like this is desirable and nice to have as an add-on api on top of whatever SAF spec specifies which would be useful and efficient at the same time:
clCkptCheckpointReadSections that can be used like this in a function to read all the sections in 1 shot:
static ClRcT testCkptRead(ClCkptHdlT ckpt) { ClCkptIOVectorElementT _pVecs = NULL; ClUint32T numVecs = 0; ClRcT rc = clCkptCheckpointReadSections(ckpt, &pVecs, &numVecs); if(rc != CL_OK) { clLogError("CKPT", "READ", "Checkpoint read all sections returned [%#x]", rc); return rc; } for(ClUint32T i = 0; i < numVecs; ++i) { ClCkptIOVectorElementT *pVec = pVecs + i; // dump log identifier for the read data clLogNotice("CKPT", "READ", "Read section [%._s] of size [%d] " "with data at [%p]", pVec->sectionId.idLen, pVec->sectionId.id, (ClUint32T)pVec->dataSize, (ClPtrT)pVec->dataBuffer); // Now process the pVec->dataBuffer for the section of pVec->dataSize // that is app. specific } // ok we are done processing. Time to tell the world we are done and no longer indispensable! if(pVecs) { clCkptIOVectorFree(pVecs, numVecs); clHeapFree(pVecs); } return CL_OK; }
Keeping @CangTranOC in the loop who got this requirement from a customer.