Costin Manolache wrote:
On 10/24/05, Remy Maucherat <[EMAIL PROTECTED]> 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 :-)
No, there's nothing for the "pure" Java connectors. I don't see the
point of trying to do it in "pure" Java, as:
- all the network code is native anyway, so it depends on if you prefer
the native network code to come from the ASF or your JVM vendor ;)
- the API exposed to do the same thing in "pure" Java (when they exist)
are unreasonably complex compared with APR
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.
Did you look at SIP and SIP servlets ? (maybe you did at Motorola) I
think the specification is complex, but it is actually designed for
doing this kind of asynchronous IO processing. I don't really understand
the point of trying to hack stuff based on the Servlet API and/or HTTP
to do asynchronous processing, since neither has been designed for that.
- 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.
This would make the programming model a lot more complex and would act
funny with web frameworks. Honestly, I'm not hot about it right now.
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
frequency.
Yes, it does add significant latency.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
