StreamSinkChannel - repeatable writes error
by Matej Lazar
Hi, I'm writing an http server for Ceylon on top of undertow.
All bytes are written to response and successfully transferred, but exception bellow occurs when shutdownWrites is called.
Stepping through a "write" method of FixedLengthStreamSinkChannel, looks like "state" is not updated correctly, it is always subtracted only for are number of bytes written in one loop.
Am I missing something or is it a bug ?
byte array size is 6919638, usually there are 147456 bytes written to a response in a loop
My code for writing bytes to response ... not quite Java, but readable ;)
shared actual void writeBytes(Array<Integer> bytes) {
//ByteBuffer.wrap
value bb = wrapByteBuffer(bytes);
value response = getResponse();
variable Integer remaining := bytes.size;
while (remaining > 0) {
variable Integer written := 0;
while((written := response.write(bb)) > 0) {
remaining -= written;
try {
response.awaitWritable();
} catch(JIOException e) {
//TODO
print(e);
}
}
}
}
Exception in thread "XNIO-1 task-2" java.lang.Error: org.xnio.channels.FixedLengthUnderflowException: 6815744 bytes remaining
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1116)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.xnio.channels.FixedLengthUnderflowException: 6815744 bytes remaining
at org.xnio.channels.FixedLengthStreamSinkChannel.shutdownWrites(FixedLengthStreamSinkChannel.java:291)
at ceylon.net.httpd.internal.HttpResponseImpl.responseDone(HttpResponseImpl.ceylon:71)
at ceylon.net.httpd.internal.CeylonRequestHandler$AsyncInvoker$1completionHandler_.handleComplete(CeylonRequestHandler.ceylon:56)
at ceylon.net.httpd.endpoints.StaticFileEndpoint.service(StaticFileEndpoint.ceylon:50)
at ceylon.net.httpd.internal.CeylonRequestHandler$AsyncInvoker.run(CeylonRequestHandler.ceylon:60)
at io.undertow.util.WorkerDispatcher$1.run(WorkerDispatcher.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
... 2 more
Thanks,
Matej.
11 years, 11 months
Proposed Low Level Web Sockets API
by Stuart Douglas
Hi Guys,
So I have just been thinking about the low level web socket API, and
basically I think it should look something like:
class WebSocketChannel {
/**
* Async receive, returns null if no frame is ready. Otherwise
returns a channel that can be used to read the frame contents.
*/
StreamSourceFrameChannel receive();
/**
* Returns a new frame channel for sending. If this is called
multiple times subsequent channels will not be writable until all
previous frame have been completed.
*/
StreamSinkFrameChannel send();
/**
* Lister to call when a new frame is ready
*/
ChannelListener.Setter<? extends WebSocketChannel> getReceiveSetter();
ChannelListener.Setter<? extends WebSocketChannel> getCloseSetter();
}
Basically once the connection is established, this channel can be used
to get FrameChannels to send and receive frames. A FrameChannel will act
like a normal Source/Sink Channel, however with some extra methods for
determining the type of frame.
the undertow integration will consist of a handler that performs the
initial handshake, and set up the connection. Once the handler has
creates this WebSocketChannel, it hands it off to the user (the user
will register a ChannelListener with the handler for this purpose), and
this is where Undertow core stops having anything to do with the
connection, and the web socket library takes over.
All higher level web socket functionality will be based on this low
level API.
Thoughts?
Stuart
12 years, 1 month
Undertow Status Report
by Stuart Douglas
Just to keep everyone in the loop I thought I would send out a quick
status report of where we are at:
Core:
A bit of time has been spent in the last week ironing out some
performance problems in the core, as the core server was performing
slower than both Grizzly and Jetty.
Several issues were found, and most have been addressed (although not
all fixes have been merged upstream yet). With these fixes we now seem
to be equal to or better than both of these. On my laptop I see us being
at least 10% faster than Jetty for basic servlet, and both Grizzly and
Undertow max out at 140,000 requests a second when using a simple async
handler, which seems to be as much as httperf can drive on my dual core
laptop.
A lot of the problem seems to be that we were doing to many volatile
writes / CAS, so we have changed the threading model slightly so these
can be removed.
Servlet:
I have setup a servlet TCK job on lightning
(http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/tck6-as7-undertow-...).
We are passing at around 85% at the moment, and these is still quite a
bit of low hanging fruit, mostly in the form of un-implemented
functionality.
In particular, the main things that are outstanding compliance wise are
Security and JSP.
Security:
Darren has started working on some proof of concept security handlers,
and I am hoping we can flesh these out a lot more and get started on the
servlet integration in the coming weeks.
AS7 Integration:
At the moment the AS7 integration is fairly basic, it allows for servlet
apps to be deployed, and has the ability to configure the listener and
the XNIO worker and that is about it.
A lot of the servlet stuff piggy backs off the existing web subsystem,
and uses the JBoss Metadata merged metadata to bootstrap Undertow.
Because of this all the EE integration is already mostly functional, the
biggest exception being web services which depends on Jboss Web internals.
I don't think there is much point focussing on this just yet, until the
Undertow API is a bit more locked down.
Everything else:
The main outstanding items at the moment as I see it are (not
integration work like web services and clustering):
- Https
- Websockets
- JSP
- AJP
- SPDY
- Reverse Proxy Support
- Transfer coding handlers
- Benchmarking suite
If anyone would like to work on any of these feel free to stick you hand
up.
Stuart
12 years, 1 month
