Stuart,
I work for a corporate company that just switched
to Java 7, and I guess it's sadly not the only one... And
since the core of Spincast itself doesn't require Java8+, we
decided to be Java7 compatible for now.
Upgrading the requirement to Java8 won't be a problem when it
will be absolutely required but, for now, we see being
Java7 compatible as a feature.
Thanks for your answer! We will useĀ a thread pool.
Julien
In this case you will want to process the data in a different thread (I would use a thread pool rather than starting a new thread each time, or you will have performance issues). If you were using the higher level JSR-356 API then Undertow has a setting to handle this automatically. I am kinda curious why you are adding JDK7 support for a new framework. JDK7 has been EOL for almost a year and as such no longer gets security updates unless you have paid for long term support. Stuart On Tue, May 31, 2016 at 4:41 AM, electrotype <electrotype@gmail.com> wrote:Hi, I'm quite new to Undertow, so please let me know if this is not the right place to ask those questions! Maybe Stack Overflow is preferred? Undertow is the default server of a new framework I'm the main developer, Spincast : https://www.spincast.org . Everything works very well, but Spincast is still in beta, we haven't really do performance testing yet. I'm not totally sure if we use Undertow properly... But, for now, everything works well. By the way, we use "Undertow 1.2.12.Final" because Spincast is Java 7 compatible. Also, we do not use the Servlet API. We're currently trying to use Undertow for Websockets in addition to HTTP. Our first tests work very well here too. But here's my question: Spincast is a synchronous Java framework. If I understand correctly, the first thing to do, when Undertow is used in such synchronous environments, is to call, in the main handler: ---------------------------------------------- if(exchange.isInIoThread()) { exchange.dispatch(this); return; } ---------------------------------------------- This is what we do. But what about Websocket messages handling? Our Webssocket server code currently looks something like this: ---------------------------------------------- WebSocketChannel channel = ... channel.getReceiveSetter().set(new AbstractReceiveListener() { @Override protected void onFullTextMessage(final WebSocketChannel channel, BufferedTextMessage bufferedTextMessage) throws IOException { String message = bufferedTextMessage.getData(); applicationHandlingOfTheMessage(message); } //... } channel.resumeReceives(); ---------------------------------------------- Here, is it correct to say that the applicationHandlingOfTheMessage(message) method shouldn't block? This code is executed in an NIO Thread, right? So we have to start a new Thread to call applicationHandlingOfTheMessage(message), is that correct? We have no idea how the application will actually handle the message. Pretty much all the code examples I found of handling such Websocket messages with Undertow are simple echos, where blocking code is not an issue. Thanks in advance! Julien _______________________________________________ undertow-dev mailing list undertow-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev