Mladen Turk wrote:

>> -----Original Message-----
>> From: news [mailto:[EMAIL PROTECTED]] On Behalf Of Costin Manolache
>> Sent: Friday, October 04, 2002 11:13 PM
>> To: [EMAIL PROTECTED]
>> Subject: RE: cvs commit:
>> jakarta-tomcat-connectors/jk/native2/common jk_wo rker_ajp13.c
>> 
>> 
>> Mladen - time for a jk2.0.2 :-) ?
>> 
> 
> Why 2.0.2, did I miss the 2.0.1 ?

I tought you already tagged 2.0.1. 

Actually, even if you did - the tag can be moved.


> That convince me even more that we need a constant service channel
> between the TC and a connector, to be able to deal with the asnyc events
> on both sides.
> I would like to see something like that in 2.1

I don't think it has to wait 2.1 - just add a component on each
side ( as 'experimental' ). I don't see how this would affect
this particular problem without too much complexity, or how it
would work for apache1.3, but it would be very good for other things.
I also need async events for the configuration side - right
now I use the shmem and the jkstatus ( to get around apache1.3
and single-threaded servers ), if you find a better solution it
would be great.

I mentioned in the comment - I think a good solution for the
errors would be a non-roundtrip error message. If a client 
error is detected, apache will send a message ( tcp is duplex ).
Tomcat will check available() before sending - it will not
wait for a message, but check if one happened to be received.
This could also take care of other async events.

BTW, I tried to get a central message dispatcher instead
of explicitely looking for particular messages - this is not
yet done, but should be close. If you reach the same conclusion
as I did ( that single threaded models don't allow an async
TCP channel ), probably we'll use the shmem and possibly a small
deamon shared by all apache instances to communicate async events to
tomcat ( and that should include statistical data for the JMX 
proxy, etc )


> As for the release, I was trying to push one even before your ajp
> bugfix, so lets go for it.
> 
> Can we make some STATUS file explaining bug fixes since 2.0.0?

Do we have one ? We should.

Costin




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to