On 23-4-2012 15:26, Daniel Pocock wrote:
Actually, apr can be a little bit more naughty than that: for Vladimir and myself, attempting to query the buffer size from APR reports the value 0. Querying the underlying socket directly reports another value. I'm using apr-1.4.2 on Debian squeeze, which version do you have?
Looking at APR's source it seems as if it only queries (on unix) if the option is set and not the actual value of the option:
apr_status_t apr_socket_opt_get(apr_socket_t *sock,
apr_int32_t opt, apr_int32_t *on)
{
switch(opt) {
default:
*on = apr_is_option_set(sock, opt);
}
return APR_SUCCESS;
}
So that seems to be the reason it returns 0.
I also noticed that the kernel doubles the value through
setsockopt/getsockopt:
SO_RCVBUF
Sets or gets the maximum socket receive buffer in bytes.
The kernel doubles this value (to allow space for bookkeeping overhead)
when it is set using setsockopt(2), and this doubled value is
returned by getsockopt(2). The default value is set by
the /proc/sys/net/core/rmem_default file, and the maximum allowed value
is set by the /proc/sys/net/core/rmem_max file. The minimum
(doubled) value for this option is 256.
So the actual size is really half of what is returned by getsockopt
You will notice the logging code reports two results, because of the apr issue described above For your patch, could you generalise it to allow a value in the config file? This commit will suggest how to go about adding a new config value: https://github.com/ganglia/monitor-core/commit/bfeb4ce3ad65466a3bef220bb6950403b4f968cd#gmond/conf.pod The patch should respect the previous behavior - if the config value is unspecified or 0, it should not change anything. However, because we know there are issues with getting/setting the value through APR, your patch would also need to consider: - is there a minimum APR version required for the patch to work?
Seems setting APR_SO_RCVBUF was added to APR in 2003 to version 0.9.4
Think to be safe I will just skip all the APR weirdness and use the native socket. Unless there might be portability issues with that?- could you set the value, query the value, and if it hasn't accepted the value, try setting the value on the native socket? - or maybe just ignore the APR code completely and go directly to set the value on the native socket?
I have a patch ready now for both method's, but seems a bit redundant to do both.
Cheers, - Ramon. -- ing. R. Bastiaans, B.ICT * Senior Systems Programmer * Operations, Support and Development SARA Science Park 140 PO Box 94613 1098 XG Amsterdam NL 1090 GP Amsterdam NL P.+31 (0)20 592 3000 F.+31 (0)20 668 3167
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
