Thanks James,
You had solve my problem i had stuck for a month.  You
are right !!! Apache spawn only one CustomLog process.
 

But it seems like Apache's "Log to pipe" feature only
works on unix.  When i try to pipe the log to a java
application in windows, it seems not working.

on unix:
  CustomLog "|java -classpath /opt pipe" common
on windows 2000:
  CustomLog "|java -classpath d:\ pipe" common
  // doesn't work in windows

I had verfiy the classpath and java path is right by
runing the java app in windows terminal.

more comment would be more than welcome.
thanks.


--- James Klicman <[EMAIL PROTECTED]> wrote:
> 
> Choose whichever language you want and don't worry.
> 
> Apache will spawn only one CustomLog process for all
> log records. It
> will only start a new process if the pipe hangs or
> the log process
> dies. It would be ridiculously inefficient if Apache
> spawned a new
> process to log each record.
> 
> -James
> 
> 
> On Sat, May 05, 2001 at 06:07:52PM -0700, tim leung
> wrote:
> > My problem is I must use unix pipe.
> > e.g. command1 xxxx | command2 xxxx
> > 
> > where command1 is some unix command.
> > where command2 is "java PipeReader"
> > 
> > that is output of command1 sent to input of java
> > application -- PipeReader.  
> > 
> > why I must use pipe?
> > because I am using apache web server.  apache
> server
> > will do logging to a text file.  instead of log to
> > text file. I can also log to a pipe :
> > 
> >   // apache server log to a pipe instead of log
> file
> >   e.g. CustomLog "|java -classpath /opt pipe"
> common
> > 
> > I pipe the log's (byte sent) / sessionID ....
> etc...
> > to the application and the application will HTTP
> POST
> > the log back to servlet for further processing.
> > 
> > the suggestion of unix pipe to a running process
> > (daemon) is what I really want to do but i dont'
> think
> > there is a way to do it.  inorder to pipe the
> > command1's Output to java app PipeReader's Input
> > (stdin).  I must invoke a new JVM process inorder
> to
> > do pipe.  right? 
> > 
> > any one can help me out?
> > thanks.
> > 
> > --- Ross Dyson <[EMAIL PROTECTED]> wrote:
> > > The JVM is loaded just ONCE not once pre
> request.
> > > 
> > > This is WHY java back-ends have better
> performance
> > > and are scalable.
> > > 
> > > -----Original Message-----
> > > From: tim leung [mailto:[EMAIL PROTECTED]]
> > > Sent: Sunday, 6 May 2001 4:39 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: JAVA vs. PERL startup time + memory
> > > 
> > > 
> > > Hi,
> > > I am thinking of write an unix app that will get
> > > data
> > > from a pipe  e.g.  |       and then will do a
> HTTP
> > > POST to some server.
> > > 
> > > e.g.  command1 xxxx  |  java PipeReader    -- OR
> --
> > > e.g.  command1 xxxx |  perl PipeReader
> > > 
> > > Assume I need to invoke the JVM process or PERL
> > > process very frequently ( 5 times / sec ) --> (
> 300
> > > times / min )
> > > 
> > > I know that Java's startup time is slow. and it
> > > allocation a block of per-defined memory when it
> > > starts up.  like 2MB. although it may only
> > > use 300KB.  so. I think start a JVM process is
> SLOW
> > > and need lots of
> > > memory.
> > > 
> > > I am not very familiar with PERL. I wonder if I
> > > invoke
> > > 300 PERL process / min, is it faster and use
> less
> > > memory than invoke 300 JVM process / min? 
> > > 
> > > Both will do the same thing.--> each time it's'
> > > invoked, it will do a HTTP POST of some data get
> > > from
> > > the pipe ( stdin ) and then System.exit(). 
> > > 
> > > thanks.
> > > 
> > >
> __________________________________________________
> > > Do You Yahoo!?
> > > Yahoo! Auctions - buy the things you want at
> great
> > > prices
> > > http://auctions.yahoo.com/
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great
> prices
> > http://auctions.yahoo.com/


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Reply via email to