Ben,
My standard approach is to have two threads per circuit. This greatly
simplifies the code and the overhead for the threads does not, IMHO, appear
to be that bad compared to what is needed for the socket, the buffering,
etc. Use of non-blocking IO can easily double the size of the code - BTDT.
In this logClient case only one thread is needed. I doubt that there would
be more than a handful of logging threads per IOC so it certainly seems like
a reasonable approach.
PS: It might be a good idea also to call shutdown for the read side of the
log client's socket in order to conserve resources. It looks like the log
server is doing this for its write side, but the log client could probably
also benefit by shutting down its read side.
Jeff
> -----Original Message-----
> From: Benjamin Franksen [mailto:[email protected]]
> Sent: Wednesday, November 16, 2005 5:07 PM
> To: [email protected]
> Subject: Re: R3.14.8 Status/logClient patch
>
>
> On Wednesday 16 November 2005 21:56, Jeff Hill wrote:
> > I did think of one issue. This is using non blocking IO after the
> > connect completes. It appears that a delta is that the logRestart
> > thread is now doing the periodic flush for *multiple* logging
> > circuits. Therefore, if one of the log circuits isnt flowing for
> > whatever reason (disk full, marginal circuit, server system
> power off,
> > etc), then all of the other log circuits will not be flushed untill
> > logClientSend is called and the specified message will not fit (the
> > buffers capacity is exceeded). Since the internal IP kernel
> timeouts
> > for circuit disconnect can be quite long this might prove to be
> > problematic.
>
> Hi Jeff,
>
> the simplest way out is to use multiple restart/flush
> threads, one for
> each log client. It appears that this has the side-advantage of
> somewhat simplifying the code since global variables are no longer
> needed.
>
> Caveat: I don't know what applications (beside the standard
> ioc log) use
> the logClient facility. If there exist applications that create a lot
> of such clients this would unduly increase IOC load. I don't believe
> that this is the case, though, it doesn't make much sense. At the
> moment I am aware of only one custom application that will use the
> feature at all, namely caPutLog, although others are conceivable.
>
> Ben
>
> PS: One could also use non-blocking send and multiplex clients with a
> select call. This would probably be more complex and also
> harder to do
> in a portable manner, thorough testing on different platforms etc. No
> way to get this into R3.14.8.
>
- Replies:
- Re: R3.14.8 Status/logClient patch Marty Kraimer
- References:
- Re: R3.14.8 Status/logClient patch Benjamin Franksen
- Navigate by Date:
- Prev:
Re: R3.14.8 Status/logClient patch Benjamin Franksen
- Next:
Re: Build system problem Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: R3.14.8 Status/logClient patch Benjamin Franksen
- Next:
Re: R3.14.8 Status/logClient patch Marty Kraimer
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|