tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [JK2] JNI worker Init complete
Date Fri, 28 Jun 2002 17:30:58 GMT
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 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.



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message