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


On 2016-05-30 23:15, Stuart Douglas wrote:
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