Last night Norman and I had a bit of a talk about what the high level
Websocket API should look like, and Norman came up with some interfaces
as a prototype.
So after looking at Norman's prototype I had a bit more of a think about
what our high level API should look like and this is what I have come up
I have been thinking about the use cases that we want to address with
the high level API, and when you would want to use the high level API vs
the low level XNIO API.
My thinking is that in general if you want to use async IO and deal with
message bytes as soon as they arrive this is covered quite nicely by our
existing low level API. The high level API should focus on async
operations involving complete messages, and blocking operations.
The JSR 356 implementation will just be implemented as a fairly thin
wrapper around our high level API.
This is handled by (Text|Binary)FrameSender.
I think there are a few different use cases for the high level API in
terms of sending messages:
- Complete message async, with a callback on completion
- Complete message blocking
- Complete message blocking with Stream / Writer
- Fragmented versions of all of the above.
There is one use case that is not covered here, and that is sending a
partial messaged using async IO, as mentioned above the reason why I
don't think we should have this as part of the high level API is because
this is essentially what is provided by our low level API.
In terms of receiving I think that we should just have a single handler
This just receives complete messages. I think this is preferable to
having to register 5 different types of handler for every frame type.
These handlers just receive complete messages that are fully buffered.
In terms of fragmented messages I think we should provide 2 ways of
dealing with them, and have a setting that controls which one is in use:
If this is true then we will just assemble the fragmented messaged
automatically and deliver it as 1 logical message. Otherwise they will
just be delivered as they arrive.
I would have liked to provide a way to receive messages via an
InputStream / Reader, to provide a way to get around fully buffering
messaged when using blocking IO, however I can't really think of a nice
way to do this.
What do you guys think? I know there is still some stuff missing (e.g.
we need a way to propagate auth and session information from the
original HTTP request).
Making use of the subsystem integration for Undertow I am getting the
error at the bottom of this message each time a request is received by
I am using Fedora 17 (About to move to 18) but I know quite a few
engineers are on OSX so just wanted to check if anyone else is
experiencing this on other operating systems? Or is it just mine? ;-)
I should add this is a cleanly built AS7/master, Undertow/master,
Undertow-Subsystem/master, AS7 started using standalone-undertow.xml and
one simple war deployed - no other changes have been made anywhere.
23:25:31,364 ERROR [org.xnio.listener] (Undertow read-1) A channel event
listener threw an exception: java.lang.OutOfMemoryError: Direct buffer
at java.nio.Bits.reserveMemory(Bits.java:658) [rt.jar:1.7.0_04]
I have the following error:
Failed tests: testWriteTimeout(io.undertow.test.WriteTimeoutTestCase):
Write did not time out
Tests run: 66, Failures: 1, Errors: 0, Skipped: 3