January 2013 - undertow-dev - Jboss List Archives

by Stuart Douglas

Hi guys, 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 with: https://github.com/stuartwdouglas/undertow/compare/websockets_high_level_api 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. Sending: 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. Receiving: In terms of receiving I think that we should just have a single handler type: https://github.com/stuartwdouglas/undertow/compare/websockets_high_level_... 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: https://github.com/stuartwdouglas/undertow/compare/websockets_high_level_... 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). Stuart

11 years, 9 months

3
8
0 / 0

AS7 Subsystem - OutOfMemoryError: Direct buffer memory

by Darran Lofthouse

Hello all, 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 the server. 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. Regards, Darran Lofthouse. 23:25:31,364 ERROR [org.xnio.listener] (Undertow read-1) A channel event listener threw an exception: java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) [rt.jar:1.7.0_04] at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) [rt.jar:1.7.0_04] at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) [rt.jar:1.7.0_04] at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:57) [xnio-api-3.1.0.Beta6.jar:3.1.0.Beta6] at org.xnio.BufferAllocator$2.allocate(BufferAllocator.java:55) [xnio-api-3.1.0.Beta6.jar:3.1.0.Beta6] at org.xnio.ByteBufferSlicePool.allocate(ByteBufferSlicePool.java:93) [xnio-api-3.1.0.Beta6.jar:3.1.0.Beta6] at io.undertow.server.HttpReadListener.handleEvent(HttpReadListener.java:89) [undertow-core-1.0.0.Alpha1-SNAPSHOT.jar:1.0.0.Alpha1-SNAPSHOT]

11 years, 10 months

3
2
0 / 0

Jenkins build became unstable: Undertow #87

by ci-builds＠redhat.com

See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/Undertow/87/>

11 years, 10 months

1
4
0 / 0

Jenkins build became unstable: Undertow » Undertow Servlet #90

by ci-builds＠redhat.com

See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/Undertow/io.undert...>

11 years, 10 months

1
1
0 / 0

Jenkins build became unstable: Undertow » Undertow WebSockets #87

by ci-builds＠redhat.com

See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/Undertow/io.undert...>

11 years, 10 months

1
3
0 / 0

build error

by jean-frederic clere

Hi, I have the following error: +++ Results : Failed tests: testWriteTimeout(io.undertow.test.WriteTimeoutTestCase): Write did not time out Tests run: 66, Failures: 1, Errors: 0, Skipped: 3 +++ Any hints? Cheers Jean-Frederic

11 years, 10 months

4
4
0 / 0

Jenkins build became unstable: Undertow » Undertow Core #87

by ci-builds＠redhat.com

See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/Undertow/io.undert...>

11 years, 10 months

1
1
0 / 0

Jenkins build became unstable: Undertow #84

by ci-builds＠redhat.com

See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/Undertow/84/changes>

11 years, 10 months

1
2
0 / 0

Jenkins build became unstable: Undertow » Undertow WebSockets #85

by ci-builds＠redhat.com

See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/Undertow/io.undert...>

11 years, 10 months

1
1
0 / 0

Jenkins build became unstable: Undertow » Undertow Core #84

by ci-builds＠redhat.com

See <http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/Undertow/io.undert...>

11 years, 10 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

undertow-dev January 2013