tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Sandbox ?
Date Mon, 24 Oct 2005 15:46:53 GMT
On 10/24/05, Remy Maucherat <> wrote:

> > For sending a file on a socket - I'm sure using apr would be faster (
> > is sendfile wrapper implemented ? ), you shouldn't have to read the
> > file in java.
> You need to look a bit into the code ;)
> There is:
> - APRized HTTP connector with sendfile and poller usage for keepalive
> - HTTPS support using OpenSSL
> - APRized AJP connector with poller usage for keepalive

I tought there is something for keepalive in the java connector as
well - I guess I was looking in the wrong place, I know apr can do all
the cool things, but I couldn't find the equivalent code.
It may be nice - and maybe that would make the apr and java code share
more code :-)

> > An unrelated subject - don't know if you saw
> >
> >
> > I don't like very much the implementation ( with Exceptions to control
> > the flow ), but I think there is a good idea to have support in the
> > thread pool to temporary release the thread for long-running servlets,
> > and then get a thread back on some event. How this is made visible to
> > servlets is debatable - I think there are few better ways than what
> > jetty is doing - but the low level is probably more important.
> I don't like it:
> - the naming is bad (this is using a poller to get read events, so it's
> basically an IO event mechanism)

Yes, the naming is horible - just some buzzwords with little
connection with the real feature.

It is a way to do even-based IO for servlets - but regardless of name,
the actual feature can be
usefull. At least for a sandbox setting :-)  Not a big priority for me
- I was hoping other people would be interested too.

> - it shouldn't just reinvoke the service method unless it can actually
> just continue transparently execution (also, in the "compatibility"
> mode, the execution path isn't the same), and creates the need for
> proprietary routing logic

I agree, the high-level doesn't look good - and it never does, for all
event-based systems :-), even those who don't try to hide this behind
a thread-based interface like service().

> - it encourages a design for servlets which will run very badly on other
> servlet containers

Well, long running servlets ( bound to events or slow IO ) will run
bad anyway on pure threads servers. But if more servers support the
concept - maybe a good solution would emerge, and become part of a
future standard. It would certainly be better than seeing it in the
next servlet spec - without enough implementation experimentation.

> It could be implemented relatively easily in the APRized connectors, but
> given the cost to process a small request over a keepalive connection
> (it's cheap; for example, the use case for this being a chat room, I
> don't see how it would perform bad if using separate requests for each
> message), I don't see any reason to support this.

In the chat room case - you can never get 'instant' messages, you
depend on the polling


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

View raw message