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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/undertow-dev