Hello,
On Tue, 25 Oct 2011 21:09:31 +0100, Alan Buxey a.l.m.bu...@lboro.ac.uk
however, as Alan said. in single thread mode, you only have one process
dealing with
requests.so one single open connection to SQL, one single sesion to
LDAP etc etc
(whatever you use) - eg even a local file
Did the very same test here, with very same results.
I find this a little bit scary to imagine that some accounting packets
are lost (meaning I have no proof the requests was answered and how.
regards
Le 26/10/2011 10:21, Pierre Rondou a écrit :
Hello,
On Tue, 25 Oct 2011 21:09:31 +0100,
Pierre Rondou wrote:
Here is what I had thought about: FreeRadius correctly treats the requests
(answer are always received), but there is a locking problem with the log
files, meaning that basically, only one thread can write inside.
Edit raddb/detail, and add locking = yes
Alan DeKok.
-
Alexandre Chapellon wrote:
Did the very same test here, with very same results.
I find this a little bit scary to imagine that some accounting packets
are lost (meaning I have no proof the requests was answered and how.
Ah... after thinking about it some more, there is no problem.
The
Pierre Rondou wrote:
The problem is that the server seems to lose accounting packets in
Multithread mode
It's possible that you're simply sending packets too fast. If the
server doesn't read them from the socket quickly enough, the kernel will
simply discard them.
Logging with module
Hello Alan,
See answers inline
Regards,
Pierre
Alan DeKok a écrit :
Pierre Rondou wrote:
The problem is that the server seems to lose accounting packets in
Multithread mode
It's possible that you're simply sending packets too fast. If the
server doesn't read them from the socket
Pierre Rondou wrote:
It's possible that you're simply sending packets too fast. If the
server doesn't read them from the socket quickly enough, the kernel will
simply discard them.
Well, then, why is this only happening in the multi-thread mode? If it
was a kernel issue, wouldn't it
Alan DeKok al...@deployingradius.com writes:
Pierre Rondou wrote:
It's possible that you're simply sending packets too fast. If the
server doesn't read them from the socket quickly enough, the kernel will
simply discard them.
Well, then, why is this only happening in the multi-thread
Bjørn Mork wrote:
File locking problem when multiple threads are attempting to update the
same file?
Maybe... the detail file is marked not thread-safe, which means that
the server core takes care of locking it. i.e. only one thread at a
time will be inside of the detail module.
Alan
On 26 October 2011 04:48, Bjørn Mork bj...@mork.no wrote:
If the server is too slow to process requests, the kernel will throw
away the UDP packets. This happens when the server is slow... whether
it's threaded or not.
But then the client won't get the acks and retransmit. If I understood
Andrej andrej.gro...@gmail.com writes:
On 26 October 2011 04:48, Bjørn Mork bj...@mork.no wrote:
If the server is too slow to process requests, the kernel will throw
away the UDP packets. This happens when the server is slow... whether
it's threaded or not.
But then the client won't get
Hi,
But then the client won't get the acks and retransmit. If I understood
correctly, then the problem is the packets *are* acked but not logged.
Maybe my whole understanding of UDP is flawed, I thought the whole
point of using UDP instead of TCP is not to have ACKS and retransmits?
at
12 matches
Mail list logo
