Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

 

Summary of work done:

  • Started by writing a new class to support multiple key objects and modifying the existing object class to reflect the same format in the log. Things got messy and confusing.
  • Finally replaced the existing object class to support variable number of keys. Now the solution is much cleaner
  • Most of the existing unit tests that used single keys had to be fixed to adhere to the new object format.
  • Object class is used more extensively now
  • Implemented a new sub-class of Buffer called ObjectBuffer that understands the new object format. It invokes functions from the Object class to restrict knowledge of the object format to one class.
  • Clients can invoke operations on this subclass object after the completion of a read RPC to parse out specific fields - keys/data blob.


IMPORTANT:

To minimize overhead and the overall cost of write operations, the format of the object in the log is tied to the format of the object's value in the rpc payload. This prevents unnecessary copying/moving of data. The RPC payload will however not the object header which is written to the log. 


Summary of client side changes:

Writes:

  • Separate write APIs for single key and multi key objects.
  • multi-key write API takes keys in the following form array[<char *key, keyLen>]
  • Still uses a single write RPC

Reads:

  • Two read APIs
    • one takes a Buffer argument (single key object read)
    • other takes an ObjectBuffer argument (multi-key object read)
  • Currently two read RPCs as well.
    • TODO: can we make do with one ??

Multiwrite:

  • Separate constructors in class MultiWriteObject for single key and multi-key objects
  • Single RPC

Multiread:

  • Currently, single RPC that returns keysAndValue
  • TODO - support for retuning just value
    • new RPC
      • involves code duplication, new subclass of MultiOpObject that takes Tub<Buffer *> as a field instead of Tub<ObjectBuffer *>
    • only one RPC but additional argument which can be a field in MultiOpObject indicating whether or not this is multikey object
      • Caveat - scope for ambiguity. Clients may invoke operations on ObjectBuffer even though ObjectBuffer may contain just the 'value' of the object.

Misc:

  • Get code review done. (in progress)
  • Ran clusterperf basic to measure overhead of the new structure/code
    • no change in read performance
    • writing single key objects - hard to conclude.
      • orig - 15.4 µs
      • now - fairly sporadic numbers between 15.1 and 16.4 µs but more in the 15.xx range.
  • No labels