[Coyote] Coyote 1.0b9 release notice

[Remy Maucherat <re...@apache.org>]

I plan to release Coyote 1.0b9 at the same time as Tomcat 4.0.4 Beta 3
(enough delays, I'm doing it later this afternoon, hopefully).

The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0
would also be released at the same time. I don't know how much this is
compatible with whatever work still needs to be done in JK2. If it's not,
then Coyote 1.0 will be released later (but obviously, it needs to be before
a 4.1.x Stable release).

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Coyote] Coyote 1.0b9 release notice

[co...@covalent.net]

On Fri, 10 May 2002, Remy Maucherat wrote:

> The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0
> would also be released at the same time. I don't know how much this is
> compatible with whatever work still needs to be done in JK2. If it's not,
> then Coyote 1.0 will be released later (but obviously, it needs to be before
> a 4.1.x Stable release).

I am just running load tests with jk2, there are few minor tweaks I'll 
commit - but everything looks fine.

The work on jk2 will continue - on the new features - but I think 
we are already functionaly equivalent with jk1, and that part is 
stable in both java and C.


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Coyote] Coyote 1.0b9 release notice

[Remy Maucherat <re...@apache.org>]

> on 5/10/02 4:42 PM, "costinm@covalent.net" <co...@covalent.net> wrote:
>
> > Well, it is a result of the new threading in the sense that now it is
> > possible to not block. If you want to bock there - it is quite easy to
> > code this :-)
> >
> > I think returning 503 is a correct behavior too - it means 'resource
> > temporary unavailable, try later' - which is exactly the case. Apache
> > should return the same result if it can't connect to tomcat.
> >
> > Costin
>
> Even if it is correct behavior in a technical sense, it isn't from a user
> sense since users don't care or know what a 503 is.
>
> Why not just block until the resource is available?
>
> I personally consider this a bug since this is changed behavior from every
> single previous release of Tomcat.
>
> So, could you please code it up if it is easy?

I changed the order of things a bit (there was a bug I had missed, which
caused the connector to be started before the rest of the pipeline, which
wasn't how it happened in the old connector), so it should behave a bit more
like the old HTTP/1.1 connector now.

I think we should add an initialize method on the endpoint, so that it is
possible to start the server socket separately from starting the connector.

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Coyote] Coyote 1.0b9 release notice

[Jon Scott Stevens <jo...@latchkey.com>]

on 5/10/02 4:42 PM, "costinm@covalent.net" <co...@covalent.net> wrote:

> Well, it is a result of the new threading in the sense that now it is
> possible to not block. If you want to bock there - it is quite easy to
> code this :-)
> 
> I think returning 503 is a correct behavior too - it means 'resource
> temporary unavailable, try later' - which is exactly the case. Apache
> should return the same result if it can't connect to tomcat.
> 
> Costin

Even if it is correct behavior in a technical sense, it isn't from a user
sense since users don't care or know what a 503 is.

Why not just block until the resource is available?

I personally consider this a bug since this is changed behavior from every
single previous release of Tomcat.

So, could you please code it up if it is easy?

-jon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Coyote] Coyote 1.0b9 release notice

[co...@covalent.net]

On Fri, 10 May 2002, Jon Scott Stevens wrote:

> My only semi-major complaint about Coyote (and I told Remy about this in
> person) is that the container now returns 503 errors until the servlet is
> started. Before, it would block (not quickly return a 503) until the servlet
> is finished starting.
> 
> Remy said it was a result of the new threading that Costin put into things.

Well, it is a result of the new threading in the sense that now it is 
possible to not block. If you want to bock there - it is quite easy to 
code this :-)

I think returning 503 is a correct behavior too - it means 'resource 
temporary unavailable, try later' - which is exactly the case. Apache 
should return the same result if it can't connect to tomcat.

Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Coyote] Coyote 1.0b9 release notice

[Jon Scott Stevens <jo...@latchkey.com>]

on 5/10/02 3:57 PM, "Remy Maucherat" <re...@apache.org> wrote:

> I plan to release Coyote 1.0b9 at the same time as Tomcat 4.0.4 Beta 3
> (enough delays, I'm doing it later this afternoon, hopefully).
> 
> The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0
> would also be released at the same time. I don't know how much this is
> compatible with whatever work still needs to be done in JK2. If it's not,
> then Coyote 1.0 will be released later (but obviously, it needs to be before
> a 4.1.x Stable release).
> 
> Remy

My only semi-major complaint about Coyote (and I told Remy about this in
person) is that the container now returns 503 errors until the servlet is
started. Before, it would block (not quickly return a 503) until the servlet
is finished starting.

Remy said it was a result of the new threading that Costin put into things.

That said, when the classloader is dumped and reloaded as a result of a
resource change, the container (properly) blocks until the servlet is
reloaded.

Now, why reloading behavior is different than startup behavior, I don't
know.

-jon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>