Costin Manolache wrote:
On 10/23/05, Remy Maucherat <[EMAIL PROTECTED]> wrote:
I'm thinking more as an 'uses' - you create ByteBuffers ( maybe direct
buffers ), and
you set it in the ByteChunk. "Extend" is not the best choice - it
would be hard to work with direct ( or other ) buffers. I'm actually
thinking about adding some static methods as well for all the utils we
have in BB.
I didn't do any tests, but accessing direct buffers contents seems
vastly more expensive. I don't see how they could be used other than for:
- buffering (as done in the APR connectors)
- transferring bytes without manipulating them in Java (ex: sending a
file on a socket)
Did you do some microbenchmarks ?
No - and I'm sure they wouldn't look very good, the current
implementation seems to just do JNI on each operation, so they are
probably more expensive
However - the fact that it is badly implemented now doesn't mean they
can't be implemented better in future or in a different VM :-), i.e.
with special support from the garbage collector, so it can be backed
by an unmovable byte[]. Realtime java JSR requires support for
unmovable objects ( afaik ) - so sooner or later we may have such a
VM, and then direct buffers would be the fastest way to communicate
between java and native.
Ok.
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
Anyway - this is just a sandbox experiment, we can try different things.
An unrelated subject - don't know if you saw
http://www.mortbay.com/MB/log/gregw/?permalink=Jetty6Continuations.html
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)
- 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
- it encourages a design for servlets which will run very badly on other
servlet containers
- the operations for saving/restoring of the request (basically
equivalent to FORM) aren't exactly cheap, as well as the usage of a poller
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.
BTW - where do we deal with keep-alive http connections ? ( I remember
you or Mladen added code to not keep the thread busy ).
The AprEndpoint does this stuff.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
