 |
 |
Hi Patrick, The "int" should be taken as is. It's a value that would fit in a signed 32-bit integer. Recall that this is xml so everything is ascii text anyway. Given the choices, #2 seems preferable in your installation. I would avoid #3. Andy ----- Original Message ----- From: "Patrick McGuigan" <[log in to unmask]> To: "Andrew Hanushevsky" <[log in to unmask]> Cc: <[log in to unmask]>; "Fabrizio Furano" <[log in to unmask]> Sent: Friday, April 30, 2010 5:11 PM Subject: Re: xrd.report vs xrd query > Hi Andy, > > > I am looking at three possible ways to send data to ganglia: > 1) use xrd.report and send reports to a single mpxstats. > > 2) use xrd.report and send report to mpxstats running on the dataserver. > > 3) use xrd and poll the data server from itself. > > I am slightly partial to #2 since it does not require a centralized > receiver, and avoids any penalty associated with a login against the > dataserver. > > Another question I have is what is the size of <int> specified in the > documentation for various values (e.g oss.paths)? > > Thanks, > > Patrick > > > Andrew Hanushevsky wrote: >> Hi Patrick, >> >>> On an idle dataserver it will forward reporting data every 10 minutes >>> when configured with xrd.report. Is this period fixed, or will it vary >>> based on activity in xrootd? >> It shouldn't. The interval is fixed though high server activity could >> delay reporting due to thread contention. >> >>> Should I expect any substantive differences between data reported by >>> xrd.report vs. manually polling the dataserver every 10 minutes using >>> the query command to xrd? >> No, they use the same code path. >> >>> I was experimenting with xrd and discovered one bug. The xrd command is >>> limited to retrieving 1K of data from a single query. The output of >>> "xrd dataserver query 1 p" is over 2K when the dataserver defines 9 >>> oss.cache groups (8 space tokens + public). >> Yes, I guess another reason to use "report". Plus is easier on the data >> server because it's one less login to process. >> >> Andy >> >