> -----Original Message----- > From: Peter B. West [mailto:[EMAIL PROTECTED]] > Sent: November 26, 2002 3:25 AM > To: [EMAIL PROTECTED] > Subject: Re: Alt-Design status: XML handling > > Rhett, > > To comment on only two aspects of your posting. > > Rhett Aultman wrote: > > > > -----Original Message----- > > From: Oleg Tkachenko [mailto:[EMAIL PROTECTED]] > > > > Generally, event-driven processing is a pretty good thing. The > critical issue with it, though, is the ratio of event production > to event processing. If that number is anything greater than 1, > then more events are being produced in a stretch of time than can > be effectively processed in that stretch of time. Events start > to queue up, taking up memory. If it happens enough, the heap > starts to get a little too full, the gc runs a little too much, > and that causes processing time to suffer even further. Under > most circumstances, event-based processing is like using a garden > hose to water a bed of flowers. It works just fine. Under more > intense cases, though, it can be more like using a garden hose to > fill a small container of water, then leaving the hose laying > around (spilling water all over the lawn) while the container > gets carried off somewhere.
Actually, it really matters where the events are coming from. An HTTP server has no control over how many requests it gets, so your description above is apt. But for FOP (disregarding FOPServlet) everything is one process - the XML parser, the formatter, the renderer - so it's ultimately procedural; there may be an internal boundary where an event/callback system is used, but it's all one thread so nothing queues up at all. The only reason to adopt your approach (and I am not saying I don't like it) is because it's easier to understand. Regards, Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
