Stefan Winter wrote:
In short: more sockets would have solved the problem. But you wouldn't want so many sockets day-to-day. Something dynamic would be a really nice feature. In a way just like the thread pool of FreeRADIUS itself is managed: define a minimum number of SQL sockets, and a min-spare, max-spare, max-total pair so that the number of connections grows and shrinks as required.
Does that feature make sense?
Yes and no. I'm wary of adding yet *another* pool implementation to the server. I'd rather just get rid of the SQL pool code entirely. Instead, it should create one SQL socket per thread, and keep re-using that in the same thread. More threads will give you more sockets. When the thread goes away, the socket can be closed, too. Alan DeKok.