[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: Configure SQL to timeout requests rather than rejecting if no connections available
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2015-01-23 2:42:30
Message-ID: 57D7DFCF-F7E3-419C-BDD5-96D6AC66C680 () deployingradius ! com
[Download RAW message or body]

On Jan 21, 2015, at 2:14 PM, Noah Engelberth <nengelberth@team-meta.net> wr=
ote:
> This made me think: "The previous change I made to make the virtual serve=
r not respond in the case of SQL failing is causing the virtual server not =
to respond the proxy, so I must need to revert that change.

  I didn=92t say to revert that change.  So...

>  But I'm kind of confused on whether or not that's the correct course of =
action, so I'm going to request clarification before I make a change, since=
 I don't have a working method of replicating this problem in my test envir=
onment right now because my test environment isn't set up to make 30+ RADIU=
S requests in a single second and resource exhaust my test RADIUS server.=
=94

  You can use radclient to hammer the server.

> I then read back through my previous postings and realized I hadn't inclu=
ded the original configuration, so I posted it in hopes that maybe my confu=
sion was stemming from a mis-communication between us caused by my failure =
to initially supply all information.

  Which is why we ask for all of the data.

> Ok, so it's apparent that I need to get an environment set up where I can=
 get debug information for the situation.  The only reason for my previous =
comments was to exhaust all other options before I started doing that, beca=
use I expected it was going to take me a couple hours to either (1) set up =
my dev environment to generate a resource exhaustion scenario or (2) learn =
enough about how to use the radius client tool to simulate the same sort of=
 setup.  =


  It takes less time to set up a debug environment than to wait for respons=
es on the list.

  I used to work with a guy whose attitude towards testing was =93I don=92t=
 have time to write tests=94.  For me, I don=92t have time to *not* write t=
ests.

> I do appreciate the effort you have put in and are continuing to put towa=
rd assisting me with my problem.  I'm disappointed by the nature of the res=
ponse I got for trying to clarify things before I spent hours generating de=
bug results, in case the confusion was stemming from something easily clear=
ed up by me including information I originally left out.

  That=92s why we ask for debug logs.  And why a good chunk of responses ar=
e questions like =93What do you mean?=94 or =93What are you really doing=94?

  If you care about privacy, send the debug messages to me off-list. I=92ll=
 take a look.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.h=
tml
[prev in list] [next in list] [prev in thread] [next in thread]