Thank you all very much, I am not alone after all. I will digest the info, apply the patch, and test the code.
regards, Richard -----Original Message----- From: Ian Cunningham [mailto:[EMAIL PROTECTED] Sent: 10 February 2006 21:21 To: Jason A. Smith Cc: Grevis, Richard: IT (LDN); Ganglia Developers Subject: Re: {Spam?} [Ganglia-developers] Re: [Ganglia-general] Early termination of XML stream from a windows based agent. Jason, Yes, my patch is the most basic kind of work around. I looked at the apr code and saw that the code implied that EAGAIN was gmond's responsibility. I don't understand socket buffers or 0_NONBLOCK so I am no help there. I do not know why it is happening. My best guess is there is some size limit in the windows tcp/ip protocol that conflicts with or differs from the way is done in unix land. I am pretty sure from reading the apr code that it is not apr's responsibility to handle the EAGAIN. However I am pretty clueless. I think there may be a more correct way to handle the EAGAIN, but I don't know what it is. One interesting side note regarding this work around with cygwin gmond which makes me think something is not 100% correct with the work around: When I was using cygwin gmonds as unicast head nodes, querying them on the xml port took a significantly (2-3x) longer to complete than a unix headnode on the same cluster. This seemed to correlate with a buffer or something blocking; it seemed like it spat out xml in spurts. Ian Jason A. Smith wrote: >Hi Ian, > >Your bug report & patch is basically to work around EAGAIN returned >from socket write calls, correct? EAGAIN is returned basically when >the socket is set to O_NONBLOCK and you have attempted a read/write on >the socket when it is not ready for that operation. The error simply >means try again later, probably because the kernel socket buffer (or >cygwin buffer layer in-between) is full and preventing the application >from writing to it. > >So the question is, why is this happening, especially when the APR >network IO code appears to be checking for EAGAIN? I have some network >code that does occasionally get EAGAIN from socket read & write system >calls, despite the fact that my event loop said that the socket was >ready for more IO. I basically do what you have done and just ignore >that return value and wait for the event loop to tell me the socket is >ready again. > >~Jason > > >On Fri, 2006-02-10 at 11:57 -0700, Ian Cunningham wrote: > > >>Richard, >> >>Please see the following bug. I have attach a patch to the bug that >>seems to work for me. >> >>http://bugzilla.ganglia.info/cgi-bin/bugzilla/show_bug.cgi?id=50 >> >>Thanks, >>Ian >> >>[EMAIL PROTECTED] wrote: >> >> >> >>>All, >>> >>>I just know that no-one else is doing this, but.... >>> >>>I updated the windows gmond with a current cygwin install and fixed >>>the processor count metric. That is all I did. Simple recompile, >>>slightly newer cygwin1.dll >>> >>>However when I used this agent, when gmetad did the tcp poll, instead >>>of the 100k of data for my farm coming back, only 8k of data was >>>returned - about 100 lines, about 8200 bytes The precise amount >>>returned varied "a little bit". And yes, 8200 is quite close to 8192. >>> >>>When I snooped the traffic I found that the windows gmond was >>>shutting the connection by sending a FIN-ACK. Not a FIN as one would >>>expect on normal termination. >>> >>>Has anyone had any experience with gmond not returning >>>all the XML stream, and just closing the link? Turning debugging on >>>does not reveal any problems or error messages. >>> >>>I must also say that the original 3.0.0 gmond.exe binary does not >>>seem to have this property. It is almost as if there is a new cygwin >>>bug lurking. >>> >>>Any ideas anyone - I have a feeling I am alone on this one... >>> >>>kind regards, >>>richard grevis >>> >>> >>>--------------------------------------------------------------------- >>>--- >>>For more information about Barclays Capital, please >>>visit our web site at http://www.barcap.com. >>> >>> >>>Internet communications are not secure and therefore the Barclays >>>Group does not accept legal responsibility for the contents of this >>>message. Although the Barclays Group operates anti-virus programmes, >>>it does not accept responsibility for any damage whatsoever that is >>>caused by viruses being passed. Any views or opinions presented are >>>solely those of the author and do not necessarily represent those of the >>>Barclays Group. Replies to this email may be monitored by the Barclays >>>Group for operational or business reasons. >>> >>>--------------------------------------------------------------------- >>>--- >>> >>> >>> >>>------------------------------------------------------- >>>This SF.net email is sponsored by: Splunk Inc. Do you grep through >>>log files for problems? Stop! Download the new AJAX search engine >>>that makes searching your log files as easy as surfing the web. >>>DOWNLOAD SPLUNK! >>>http://sel.as-us.falkag.net/sel?cmd=k&kid3432&bid#0486&dat1642 >>>_______________________________________________ >>>Ganglia-general mailing list >>>[EMAIL PROTECTED] >>>https://lists.sourceforge.net/lists/listinfo/ganglia-general >>> >>> >>> >>> >>> >> >>------------------------------------------------------- >>This SF.net email is sponsored by: Splunk Inc. Do you grep through log >>files for problems? Stop! Download the new AJAX search engine that >>makes searching your log files as easy as surfing the web. DOWNLOAD >>SPLUNK! >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=1216 42 >>_______________________________________________ >>Ganglia-developers mailing list >>Ganglia-developers@lists.sourceforge.net >>https://lists.sourceforge.net/lists/listinfo/ganglia-developers >> >> >> ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------
