Hi Matt, As an "outsider" (but as a coder), I've a few thoughts:
I'd say you want to be as flexible as possible. You're actual limitation is that the four field lengths must add up to 1456 or less. In my view it's this limit you should be enforcing: the MAX_GMETRIC_XDR_TYPE_LEN of 12 bytes is an artificial constraint -- perhaps not unreasonable, but an unnecessary one. I'm not sure of the on-wire encoding, but will the gmetric message change be backward compatible? Will the new gmetric message be accepted by older gmond and visa-versa? If its not backward compatible, wouldn't changing the message type be sensible (i.e. keep the existing gmetric message and add an additional one)? If you do decide for specific string partitioning, I'd trade some of the VALUE length for NAME length. Allowing only 36 bytes is a bit stingy (I have some long names!). Perhaps ~50 would be better, the difference for the VALUE field would be small (or do people have large values they want to send?) Finally, as a proposal, how about introducing an additional field for grouping. It would be nice if gmetric data could be plotted on the same graph as some regular data is currently. The protocol could include a hint that certain gmetric data should be displayed on a single graph. I can put together a more detailed suggestion, if people are interested in this. Cheers, Paul. On Friday 03 Mar 2006 06:27, matt massie wrote: > guys- > > i took the time tonight to update the Gmetric message code in order > to prevent data corruption and to ensure you get immediate feedback > when you try to pack too much data in the message in gmetric. > > i only needed to update the following files > ./gmetric/gmetric.c > ./lib/ganglia.h > ./lib/libgmond.c > ./lib/protocol.x > > i tagged those four files with "preGmetricMessageUpdate" > before > committing my changes in order to make it easy to back out the > changes if necessary. i've only compiled the code on MacOS X Tiger. > > can you please review the changes and test them on your favorite OS > and give feedback? please feel free to debate the sizes of the > following definitions as well... > #define MAX_GMETRIC_XDR_TYPE_LEN 12 > #define MAX_GMETRIC_XDR_NAME_LEN 36 > #define MAX_GMETRIC_XDR_VALUE_LEN 1396 > #define MAX_GMETRIC_XDR_UNITS_LEN 12 > > in protocol.x. we can take from one to add to the other but the four > must add to 1456.
pgppjTmTka0Qq.pgp
Description: PGP signature
