(RADIATOR) Input queue size

[Hugh Irvine]

Hello Matthew -

You are quite correct. Radiator does an "open-write-close" for every 
log event.

In spite of this however I would not recommend having more than one 
Radiator instance writing to a log file as it becomes almost impossible 
to then understand what is going on. It is _much_ better to set up your 
logging using GlobalVar's passed in on the startup command line. This 
way you can have the same configuration file but have different 
instances logging to different files.

regards

Hugh


On 14/11/2003, at 3:51 AM, Matthew Trout wrote:

> All radiator log accesses e done lock-write-unlock, IIRC, so you 
> should be
> fine.
>
> I'd suggest double-checking with either the docs, the source, or Hugh 
> before
> putting it on a production system :)
>
>> -----Original Message-----
>> From: Vangelis Kyriakakis [mailto:vkyriak at forthnet.gr]
>> Sent: 13 November 2003 08:59
>> Cc: radiator at open.com.au
>> Subject: Re: (RADIATOR) Input queue size
>>
>>
>> Can all these Radiator instances use the same logfiles? Or
>> they'll have
>> problems racing for file locks?
>>
>>           Vangelis
>>
>> Frank Danielson wrote:
>>
>>> It's really not that hard. You run a number of Radiator
>> instances, with each
>>> one having it's own connection to the LDAP, SQL, or whatever
>> backend. Then
>>> you front end those with an instance or two of Radiator
>> running AuthBy
>>> ROUNDROBIN or AuthBy LOADBALANCE to distribute the requests
>> among them.
>>>
>>> You can process quite a lot of requests simultaneously this
>> way. If your
>>> current server is not responding fast enough but the CPU
>> utilization is not
>>> maxed out you are probably just hitting the ceiling on how
>> many requests a
>>> single instance can process at a time. Start up some more
>> processes on the
>>> box and use all those processor cycles that you paid for.
>>>
>>> -Frank
>>>
>>> -----Original Message-----
>>> From: Claudio Lapidus [mailto:c_lapidus at hotmail.com]
>>> Sent: Wednesday, November 12, 2003 9:19 PM
>>> To: Guðbjörn S. Hreinsson; radiator at open.com.au
>>> Subject: Re: (RADIATOR) Input queue size
>>>
>>> ......
>>>
>>>> From my own corner, I wish it were possible to have more than one
>>> established connection with the SQL backend, so as to
>> paralellize requests
>>> to a certain degree. But yes, I suppose that means
>> multithreading, and AFAIK
>>> that's not possible under perl 5.6 nor 5.8 I think. Perhaps
>> Perl 6 would do
>>> it?
>>>
>>> ===
>>> Archive at http://www.open.com.au/archives/radiator/
>>> Announcements on radiator-announce at open.com.au
>>> To unsubscribe, email 'majordomo at open.com.au' with
>>> 'unsubscribe radiator' in the body of the message.
>>>
>>>
>>>
>>
>>
>> ===
>> Archive at http://www.open.com.au/archives/radiator/
>> Announcements on radiator-announce at open.com.au
>> To unsubscribe, email 'majordomo at open.com.au' with
>> 'unsubscribe radiator' in the body of the message.
>>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.