Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 46866 invoked from network); 28 Jun 2002 17:32:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by 209.66.108.5 with SMTP; 28 Jun 2002 17:32:11 -0000 Received: (qmail 22053 invoked by uid 97); 28 Jun 2002 17:32:14 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 21921 invoked by uid 97); 28 Jun 2002 17:32:10 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 21869 invoked by uid 98); 28 Jun 2002 17:32:09 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Fri, 28 Jun 2002 10:30:58 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Tomcat Developers List cc: nacho@apache.org Subject: RE: [JK2] JNI worker Init complete In-Reply-To: <003e01c21e68$957a7da0$5c00000a@GISDATA.ZG> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N On Fri, 28 Jun 2002, Mladen Turk wrote: > > When tomcat is started inprocess ( by JNI ) we need a way to > > signal when tomcat ( 3.3 and 4.1.X ) initialization is > > complete, and make jk2 wait until that signal to start > > redirecting request to the JNI worker.. > > I have the same problems, (I've posted that on Monday)... > The problem is also with the channel itself, cause the first invocation > of channel.open takes some time, but I solved that cause there was the > multithreading bug in the code. I agree - that would be an ENGINE_STARTED callback in coyote, to be called when tomcat is ready to serve requests. One big issue with the current startup - all context initialization is done serially and is blocking the tomcat startup. That has a number of problems, including scalability ( if you have 100s of webapps on a large server, some with expensive initalization in on-startup servlets - it can take a lot of time to start). I think we need 2 messages - one when the engine is ready ( but not all contexts load-on-startup ), and one when all the webapps are ready. What do we do if a webapp hungs in servlet.init() ? The whole container will be blocked by one bad app. Probably that should be solved in 5.0, for now just an engine ready would be enough on java side, and that should set a flag ( using the setAttribute() call ) on the channel. > >I think i will need too another kind of invoke message, to > > signal inited state from tomcat, from Coyote/JK2.., any help > > is welcomed.. > There is no need to do that for initialization. All that we require is > the worker startup flag, with the timeout probably. > Second large improvement would be (think you meant that) the > introduction of a special fixed single 'maintenance' channel, that could > be used for server<->TC communication, sending status and control > messages like restart/shutdown/busy/resource, etc... Running as a > separate thread (or something like that) for each TC-channel combination > in the load balancer. For control messages - I think setAttribute/getAttribute is enough, and I would like to keep it simple. We can add a thread or some more advanced mechansims, but I would like the API to remain simple ( well, to become plain JMX on java side ). For JNI things are simple(r), what's harder is support the full setAttribute/getAttribute protocol over TCP and other channels. The same 'server starter' message should be sent for tcp channels, not only JNI. > I'm pretty close to the first solution (disabling all communication > until the first worker call succeeds, in the preset timeout), and I'll > post it for review when I thoroughly test it. Great. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: