AW: [omniORB] omniORB::log and omniORB::logger and syslog

[Grobarcik Peter]

Hi all,
 
I would like to express a wish If it is posssible. In a complicated network
setup (like ours) it would be wery handy to have timestamps in each
log-line, at least in the invocation-tracing. We are offten confronted with
problems like sudenly a service has some reply latencies of more than a
minute and we need to determine the component responsible: it is the
database? the sockets/network? are the data structures being transported
really so complicated/big (~1000 structures in a sequence)? or some other
thing? When we could see that the omniORB component is working "fluently" -
without pulsations, we would have a problem less.

Cheers,

Peter


> ----------
> Von: 	Duncan Grisby[SMTP:dgrisby@uk.research.att.com]
> Gesendet: 	Donnerstag, 1. November 2001 11:15
> An: 	David Byron
> Cc: 	omniorb-list@uk.research.att.com
> Betreff: 	Re: [omniORB] omniORB::log and omniORB::logger and syslog 
> 
> On Monday 29 October, David Byron wrote:
> 
> > I'm also curious why both omniORB::log and omniORB::logger exist.
> > omniORB::logger writes to a small memory buffer and then only calls
> > fprintf(stderr) in its destructor.  omniORB::logger also doesn't
> > fflush(stderr), but omniORB::log does.  This would make sense to me if
> > omniORB::logger was used in places where time or swapping was a big
> > consideration, perhaps because stderr was connected to a 9600 baud
> terminal.
> 
> omniORB::log only exists for historical reasons. If you look at the
> omniORB 4 tree, you'll see that it's gone. omniORB::logger buffers its
> output before writing it upon destruction so that output from
> different threads doesn't overlap.
> 
> I think Michael Accetta's suggestion (and patch) of a hook function is
> the best way to go. omniORB 4 has made some things more simple, and
> complicated others. I'll add it to my list of things to think about
> before release.
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --
>