Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 52289 invoked from network); 7 Jun 2002 14:09:43 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Jun 2002 14:09:43 -0000 Received: (qmail 21389 invoked by uid 97); 7 Jun 2002 14:09:44 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 21354 invoked by uid 97); 7 Jun 2002 14:09:43 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 21303 invoked by uid 98); 7 Jun 2002 14:09:42 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Reply-To: From: "Berin Loritsch" To: "'Vadim Gritsenko'" , , "'Avalon Developers List'" Subject: RE: [Design] ContainerManager is under fire--let's find the best resolution Date: Fri, 7 Jun 2002 10:09:19 -0400 Message-ID: <002d01c20e2c$ead54330$ac00a8c0@Gabriel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <00bd01c20e29$574f7bb0$0a00a8c0@vgritsenkopc> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]=20 >=20 > JDBC connection must be aware of pooling (special handling in the > close() method), which does not look good - current Avalon=20 > model where poolable component must not care about how it is=20 > being pooled is *much* better. The connection itself is not aware of it. In fact you can use just about any vendor's JDBC driver with the same DataSourceComponent. The DataSourceComponent wraps the JDBC driver with a proxy--just like the DataSource spec says. It's not that difficult to do. > > I am advocating the same thing for the CM >=20 > Do you propose to make pooling concern of the component?=20 > (I.e., manual pooling as in JDBC?) I am for supporting components up the the Per-Thread request model, and anything that needs a Per-Lookup request model needs to be redesigned. This allows the container to be smart about the instances. It can either use ThreadLocals to create the Components (too slow on JDK 1.2 and before), or a finite number of components to share between the threads. The number of component instances really shouldn't exceed the number of threads. Consider Cocoon. The Transformer is a Per-Lookup design. This is too limiting. Let's assume we have a pipeline with 5 transformers. That means the pool for the transformer must be 5*Tn where Tn is the number of threads. Even if we cut this to 70% of the value, Servlet engines can have anywhere between 20 to 100 threads handling incoming requests. So we are talking at least 70 components and at most 500 used at any one time. Worse, certain optimizations on the usage of the artifacts become much more difficult to assemble. Certain things like caching mechanisms have to be worked into the scheme of things across multiple component instances as opposed to each component type. Furthermore, you cannot directly substitute a cached resource for the original. With the current state of affairs, it is very difficult to understand why Cocoon uses 50-60 MB of RAM for even the simplest of systems. Overpooling is an antipattern just as underpooling is. We need to use more judicious pooling mechanisms--ones that are smarter. I highly recommend looking at Fortress in Excalibur for a better pool mechanism. Fortress can do everything ECM can do, and do it quicker and faster, with self discovering pools sizes. I highly recommend it. Things like releasing the components no longer slow down the critical path of processing requests. It is faster to start up, faster to use, but slower to completely shut down. That's OK, because Cocoon can use a quicker startup time and could stand to process requests even faster. In low simultaneous thread counts such as 10 to 15 threads, there isn't a lot of difference between ECM and Fortress in the time it takes to lookup and release components. However, under high load with upwards of 100 threads or more, Fortress kills ECM in performance by a factor of 16 (and in some cases even more). The main reason is the gentler saturation curve because of asynchronous releasing of components. In a world where we did not need to release components explicitly, we would see even better improvements. The higher abstraction that I advocate actually helps organize thoughts and enable the easier integration of optimization possibilities. -- To unsubscribe, e-mail: For additional commands, e-mail: