Re: [Condor-users] Do the following settings remove all UDP communication from a Condor pool?

[Ian Chesal <ichesal@xxxxxxxxxxxxxxxxxx>]

On Monday, 15 August, 2011 at 10:59 AM, Dan Bradley wrote:

Ian,

I believe the settings you mentioned will achieve what you are trying to do.  In 7.6, it should also be sufficient to do this:

WANT_UDP_COMMAND_SOCKET = false
UPDATE_COLLECTOR_WITH_TCP = True

COLLECTOR_MAX_FILE_DESCRIPTORS = 3000

In 7.6, daemons that do not have a UDP port advertise this fact in their address information.  Therefore, it is not necessary to fiddle with protocol knobs such as SCHEDD_SEND_VACATE_VIA_TCP, because the client automatically switches to TCP when it sees that the server lacks a UDP port.

Thanks Dan! That's sufficient incentive for me to ensure everything is 7.6.x in my pool then. Right now I'm running a 7.4.3 scheduler and CM, but 7.6.1 on the execute node.

For what it's worth, this is all to debug an issue I'm seeing on a large CPU count Windows 2k8 Server machine. It has 40 physical cores but Condor only seems to be able to utilize 12 slots on the box before it starts to fail to accept claims from the shadows with:

08/10/11 18:29:50 Received TCP command 444 (ACTIVATE_CLAIM) from unauthenticated@unmapped <10.78.194.211:40724>, access level DAEMON

08/10/11 18:29:50 Calling HandleReq <command_activate_claim> (0)

08/10/11 18:29:50 slot25: Got activate_claim request from shadow (<10.78.194.211:40724>)

08/10/11 18:30:06 condor_write(): Socket closed when trying to write 13 bytes to <10.78.194.211:40724>, fd is 1356

08/10/11 18:30:06 Buf::write(): condor_write() failed

08/10/11 18:30:06 slot25: Can't send eom to shadow.

08/10/11 18:30:06 Return from HandleReq <command_activate_claim> (handler: 15.615s, sec: 0.016s)

08/10/11 18:30:06 Received TCP command 444 (ACTIVATE_CLAIM) from unauthenticated@unmapped <10.78.194.211:59675>, access level DAEMON

08/10/11 18:30:06 Calling HandleReq <command_activate_claim> (0)

08/10/11 18:30:06 slot16: Got activate_claim request from shadow (<10.78.194.211:59675>)

08/10/11 18:30:09 condor_write(): Socket closed when trying to write 13 bytes to <10.78.194.211:59675>, fd is 1356

08/10/11 18:30:09 Buf::write(): condor_write() failed

08/10/11 18:30:09 slot16: Can't send eom to shadow.

08/10/11 18:30:09 Return from HandleReq <command_activate_claim> (handler: 2.496s, sec: 0.016s)

I realize that's TCP traffic but I was wondering if UDP communications from the shadows trying to get in touch with the startd on the box were causing problems in general for the Windows networking stack.

Since the address of the collector is hard-coded into the configuration file, there are two options: one is to use UPDATE_COLLECTOR_WITH_TCP, as in the above example.  The other is to add the "noUDP" flag to the collector address.  Example:

COLLECTOR_HOST = mycollector.host.name:9618?noUDP

I've still got 7.4.3 execute nodes in the pool -- will they they recognize this flag? 

Regards,

- Ian

---

Ian Chesal

Cycle Computing, LLC

Leader in Open Compute Solutions for Clouds, Servers, and Desktops

Enterprise Condor Support and Management Tools

http://www.cyclecomputing.com

http://www.cyclecloud.com

http://twitter.com/cyclecomputing