From ceharris at vt.edu  Mon May  9 10:21:48 2016
From: ceharris at vt.edu (Harris, Carl)
Date: Mon, 9 May 2016 14:21:48 +0000
Subject: [undertow-dev] create session in handler
Message-ID: <D0DCAACF-B550-4524-AABD-0A0D75C77303@vt.edu>

In a handler that is part of my servlet extension, I want to be able to create a session using SessionManager.

Looks like I could get the relevant manager from the HttpExchange using the attachment key declared in the SessionManager interface. I'm not quite sure what to pass as the SessionConfig argument to createSession.  It looks like there are two implementations of SessionConfig; one that uses the JSESSIONID cookie, and another that uses the SSL session.

The SslSessionConfig takes a fallback config, and so it looks like this might be the right thing to do:

SessionConfig sessionConfig = new SslSessionConfig(new SessionCookieConfig(), sessionManager);


Just looking for confirmation or correction.

Thanks,

carl





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20160509/c1f83198/attachment.bin 

From oliver at analyticspot.com  Tue May 10 20:54:39 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Wed, 11 May 2016 00:54:39 +0000
Subject: [undertow-dev] receiveFullBytes callbacks never called
Message-ID: <CACSC6EUzQRM6W0kaRcSyt8iSu993GZbWBX7gX2_GVre1PvD4qg@mail.gmail.com>

I've got a case where I can call receiveFullBytes but neither the success
nor the error handler is ever called. My code looks like this:

public static CompletableFuture<ByteSource>
getCompleteBody(HttpServerExchange exchange) {
  log.debug("In getCompleteBody.");
  CompletableFuture<ByteSource> finalResult = new CompletableFuture<>();
  try {
    log.debug("Calling receiveFullBytes.");
    exchange.getRequestReceiver().receiveFullBytes(
        // Success case.
        (HttpServerExchange excng, byte[] bytes) -> {
          log.debug("getFullBytes completed with success.");
          finalResult.complete(ByteSource.wrap(bytes));
        },

        // Error case
        (HttpServerExchange exchng, IOException t) -> {
          log.warn("getFullBytes completed with an error:", t);
          finalResult.completeExceptionally(t);
        }
    );
  } catch (Throwable t) {
    log.warn("receiveFullBytes threw an exception:", t);
    finalResult.completeExceptionally(t);
  }

  return finalResult;
}

I've got a unit test that opens a socket, starts sending data, and
then, intentionally throws an exception. The test then ensures that
the CompletableFuture above completes with an exception. Except, it
never completes.. the test just hangs forever. You can see that the
"log.debug("Calling receiveFullBytes.")" line does get called and that
the neither of the log lines in either callback is ever called. The
full test looks like this:

@Test
public void getCompleteBodyCompletesWithExceptionOnBodyFailure()
throws Exception {
  AtomicBoolean futureRedeemedWithError = new AtomicBoolean(false);
  CountDownLatch waitForInputToFail = new CountDownLatch(1);

  HttpHandler handler = new HttpHandler() {
    @Override
    public void handleRequest(HttpServerExchange exchange) throws Exception {
      log.info("Handler called.");
      exchange.dispatch();
      log.info("Calling getCompleteBody");
      UndertowUtils.getCompleteBody(exchange).exceptionally((Throwable t) -> {
        log.debug("As expected, received an exception:", t);
        futureRedeemedWithError.set(true);
        waitForInputToFail.countDown();
        return null;
      });
    }
  };
  UndertowTestUtils.RunningServer server =
UndertowTestUtils.startUndertowOnFreePort(handler);

  // A Body() implementation that will return a few chunks of data but the fail
  Body failingRequestBody = new Body() {
    private AtomicInteger readCalls = new AtomicInteger(0);
    @Override
    public long getContentLength() {
      return 1000;
    }

    @Override
    public long read(ByteBuffer buffer) throws IOException {
      if (readCalls.getAndIncrement() < 2) {
        byte[] toSend = "some data".getBytes(Charsets.UTF_8);
        buffer.put(toSend);
        return toSend.length;
      } else {
        throw new RuntimeException("Fake error on sending data.");
      }
    }

    @Override
    public void close() throws IOException {
    }
  };

  // A body generator using the above, busted Body.
  BodyGenerator failingBodyGenerator = new BodyGenerator() {
    @Override
    public Body createBody() throws IOException {
      return failingRequestBody;
    }
  };

  // This will start sending data so our handler gets invoked but it
will then fail partway through.
  SimpleAsyncHttpClient client = new SimpleAsyncHttpClient.Builder()
      .setUrl(String.format("http://localhost:%s", server.getPort()))
      .build();

  client.post(failingBodyGenerator);


  // Test hangs here forever
  waitForInputToFail.await();

  assertThat(futureRedeemedWithError.get()).isTrue();
}


This feels like a bug. I'd expect the contract of "receiveFullBytes" to be
that either the success or failure handler gets called exactly once. Is
this a bug? If not, what am I doing wrong?

Thanks,

Oliver

-- 
CTO, Analytic Spot
44 West Broadway #222
Eugene, OR 97401
analyticspot.com ? 425-296-6556
www.linkedin.com/in/oliverdain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160511/c79efc4e/attachment-0001.html 

From brian.call at primacinema.com  Wed May 11 16:39:57 2016
From: brian.call at primacinema.com (Brian Call)
Date: Wed, 11 May 2016 13:39:57 -0700
Subject: [undertow-dev] java.lang.IllegalStateException: UT000124:
	renegotiation timed out
Message-ID: <377C47DC-20DD-401D-BE1F-2CAEC75B3219@primacinema.com>

Hi Guys,

First off, I?m trying to figure out whether or not I?m dealing with a bug or a user error on this one, so my apologies for spamming everyone. There is scant information pertaining to this error anywhere that I found as google only returned a single result, and that was to the messages class containing the message code. 

I?m seeing this exception on TLS negotiation using client certs and I just can?t figure out what?s being renegotiated or why there would be a timeout. It?s all happening in milliseconds so I?m very confused, especially since it seems to happen intermittently and under varying circumstances. I?ve examined the source code for the wildly-10 version undertow that I?m using and I just can?t figure it out. Any hints in the right direction would be greatly appreciated. 

Blessings,
Brian

Here?s the stack trace:

2016-05-11 20:27:51,766 ERROR [io.undertow.request] (default task-7) UT005023: Exception handling request to /ppi/whoami: java.lang.IllegalStateException: UT000124: renegotiation timed out
	at io.undertow.server.ConnectionSSLSessionInfo.renegotiateNoRequest(ConnectionSSLSessionInfo.java:175)
	at io.undertow.server.ConnectionSSLSessionInfo.renegotiate(ConnectionSSLSessionInfo.java:89)
	at io.undertow.security.impl.ClientCertAuthenticationMechanism.getPeerCertificates(ClientCertAuthenticationMechanism.java:125)
	at io.undertow.security.impl.ClientCertAuthenticationMechanism.authenticate(ClientCertAuthenticationMechanism.java:92)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
	at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
	at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
	at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160511/b2906d1a/attachment.html 

From sdouglas at redhat.com  Thu May 12 08:20:09 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 12 May 2016 22:20:09 +1000
Subject: [undertow-dev] create session in handler
In-Reply-To: <D0DCAACF-B550-4524-AABD-0A0D75C77303@vt.edu>
References: <D0DCAACF-B550-4524-AABD-0A0D75C77303@vt.edu>
Message-ID: <CAD+L2cyU+rqr55poCWUD7NVX5FxwBzo1ggpL=eDWC2F1uNMadg@mail.gmail.com>

You probably want to get hold of the ServletContextImpl and call
getSession, the correct implementation of SessionConfig to use will
depend on the configuration of the servlet deployment (and in general
SSL is not recommended, as modern browsers may create multiple SSL
sessions).

Stuart

On Tue, May 10, 2016 at 12:21 AM, Harris, Carl <ceharris at vt.edu> wrote:
> In a handler that is part of my servlet extension, I want to be able to create a session using SessionManager.
>
> Looks like I could get the relevant manager from the HttpExchange using the attachment key declared in the SessionManager interface. I'm not quite sure what to pass as the SessionConfig argument to createSession.  It looks like there are two implementations of SessionConfig; one that uses the JSESSIONID cookie, and another that uses the SSL session.
>
> The SslSessionConfig takes a fallback config, and so it looks like this might be the right thing to do:
>
> SessionConfig sessionConfig = new SslSessionConfig(new SessionCookieConfig(), sessionManager);
>
>
> Just looking for confirmation or correction.
>
> Thanks,
>
> carl
>
>
>
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From sdouglas at redhat.com  Thu May 12 08:21:25 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 12 May 2016 22:21:25 +1000
Subject: [undertow-dev] receiveFullBytes callbacks never called
In-Reply-To: <CACSC6EUzQRM6W0kaRcSyt8iSu993GZbWBX7gX2_GVre1PvD4qg@mail.gmail.com>
References: <CACSC6EUzQRM6W0kaRcSyt8iSu993GZbWBX7gX2_GVre1PvD4qg@mail.gmail.com>
Message-ID: <CAD+L2cxwQ83q-ec8a1KCXEDN7z+E9=FgW-A_Q+YmhrufqO72NA@mail.gmail.com>

This sounds like a bug, can you file a JIRA? I am traveling at the
moment but I will investigate when I get back.

Stuart

On Wed, May 11, 2016 at 10:54 AM, Oliver Dain <oliver at analyticspot.com> wrote:
> I've got a case where I can call receiveFullBytes but neither the success
> nor the error handler is ever called. My code looks like this:
>
> public static CompletableFuture<ByteSource>
> getCompleteBody(HttpServerExchange exchange) {
>   log.debug("In getCompleteBody.");
>   CompletableFuture<ByteSource> finalResult = new CompletableFuture<>();
>   try {
>     log.debug("Calling receiveFullBytes.");
>     exchange.getRequestReceiver().receiveFullBytes(
>         // Success case.
>         (HttpServerExchange excng, byte[] bytes) -> {
>           log.debug("getFullBytes completed with success.");
>           finalResult.complete(ByteSource.wrap(bytes));
>         },
>
>         // Error case
>         (HttpServerExchange exchng, IOException t) -> {
>           log.warn("getFullBytes completed with an error:", t);
>           finalResult.completeExceptionally(t);
>         }
>     );
>   } catch (Throwable t) {
>     log.warn("receiveFullBytes threw an exception:", t);
>     finalResult.completeExceptionally(t);
>   }
>
>   return finalResult;
> }
>
> I've got a unit test that opens a socket, starts sending data, and then,
> intentionally throws an exception. The test then ensures that the
> CompletableFuture above completes with an exception. Except, it never
> completes.. the test just hangs forever. You can see that the
> "log.debug("Calling receiveFullBytes.")" line does get called and that the
> neither of the log lines in either callback is ever called. The full test
> looks like this:
>
> @Test
> public void getCompleteBodyCompletesWithExceptionOnBodyFailure() throws
> Exception {
>   AtomicBoolean futureRedeemedWithError = new AtomicBoolean(false);
>   CountDownLatch waitForInputToFail = new CountDownLatch(1);
>
>   HttpHandler handler = new HttpHandler() {
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception
> {
>       log.info("Handler called.");
>       exchange.dispatch();
>       log.info("Calling getCompleteBody");
>       UndertowUtils.getCompleteBody(exchange).exceptionally((Throwable t) ->
> {
>         log.debug("As expected, received an exception:", t);
>         futureRedeemedWithError.set(true);
>         waitForInputToFail.countDown();
>         return null;
>       });
>     }
>   };
>   UndertowTestUtils.RunningServer server =
> UndertowTestUtils.startUndertowOnFreePort(handler);
>
>   // A Body() implementation that will return a few chunks of data but the
> fail
>   Body failingRequestBody = new Body() {
>     private AtomicInteger readCalls = new AtomicInteger(0);
>     @Override
>     public long getContentLength() {
>       return 1000;
>     }
>
>     @Override
>     public long read(ByteBuffer buffer) throws IOException {
>       if (readCalls.getAndIncrement() < 2) {
>         byte[] toSend = "some data".getBytes(Charsets.UTF_8);
>         buffer.put(toSend);
>         return toSend.length;
>       } else {
>         throw new RuntimeException("Fake error on sending data.");
>       }
>     }
>
>     @Override
>     public void close() throws IOException {
>     }
>   };
>
>   // A body generator using the above, busted Body.
>   BodyGenerator failingBodyGenerator = new BodyGenerator() {
>     @Override
>     public Body createBody() throws IOException {
>       return failingRequestBody;
>     }
>   };
>
>   // This will start sending data so our handler gets invoked but it will
> then fail partway through.
>   SimpleAsyncHttpClient client = new SimpleAsyncHttpClient.Builder()
>       .setUrl(String.format("http://localhost:%s", server.getPort()))
>       .build();
>
>   client.post(failingBodyGenerator);
>
>
>   // Test hangs here forever
>   waitForInputToFail.await();
>
>   assertThat(futureRedeemedWithError.get()).isTrue();
> }
>
>
> This feels like a bug. I'd expect the contract of "receiveFullBytes" to be
> that either the success or failure handler gets called exactly once. Is this
> a bug? If not, what am I doing wrong?
>
> Thanks,
>
> Oliver
>
> --
> CTO, Analytic Spot
> 44 West Broadway #222
> Eugene, OR 97401
> analyticspot.com ? 425-296-6556
> www.linkedin.com/in/oliverdain
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev


From karm at redhat.com  Thu May 12 09:10:37 2016
From: karm at redhat.com (Michal Karm Babacek)
Date: Thu, 12 May 2016 09:10:37 -0400 (EDT)
Subject: [undertow-dev] java.lang.IllegalStateException:
	UT000124:	renegotiation timed out
In-Reply-To: <377C47DC-20DD-401D-BE1F-2CAEC75B3219@primacinema.com>
References: <377C47DC-20DD-401D-BE1F-2CAEC75B3219@primacinema.com>
Message-ID: <1021079365.2053111.1463058637936.JavaMail.zimbra@redhat.com>

Brian, could you start the server with -Djavax.net.debug=ssl
and pastebin the surroundings  of the exception?

Cheers
-K-

----- Original Message -----
> From: "Brian Call" <brian.call at primacinema.com>
> To: undertow-dev at lists.jboss.org
> Sent: Wednesday, May 11, 2016 10:39:57 PM
> Subject: [undertow-dev] java.lang.IllegalStateException: UT000124:	renegotiation timed out
> 
> Hi Guys,
> 
> First off, I?m trying to figure out whether or not I?m dealing with a bug or
> a user error on this one, so my apologies for spamming everyone. There is
> scant information pertaining to this error anywhere that I found as google
> only returned a single result, and that was to the messages class containing
> the message code.
> 
> I?m seeing this exception on TLS negotiation using client certs and I just
> can?t figure out what?s being renegotiated or why there would be a timeout.
> It?s all happening in milliseconds so I?m very confused, especially since it
> seems to happen intermittently and under varying circumstances. I?ve
> examined the source code for the wildly-10 version undertow that I?m using
> and I just can?t figure it out. Any hints in the right direction would be
> greatly appreciated.
> 
> Blessings,
> Brian
> 
> Here?s the stack trace:
> 
> 2016-05-11 20:27:51,766 ERROR [io.undertow.request] (default task-7)
> UT005023: Exception handling request to /ppi/whoami:
> java.lang.IllegalStateException: UT000124: renegotiation timed out
> 	at
> 	io.undertow.server.ConnectionSSLSessionInfo.renegotiateNoRequest(ConnectionSSLSessionInfo.java:175)
> 	at
> 	io.undertow.server.ConnectionSSLSessionInfo.renegotiate(ConnectionSSLSessionInfo.java:89)
> 	at
> 	io.undertow.security.impl.ClientCertAuthenticationMechanism.getPeerCertificates(ClientCertAuthenticationMechanism.java:125)
> 	at
> 	io.undertow.security.impl.ClientCertAuthenticationMechanism.authenticate(ClientCertAuthenticationMechanism.java:92)
> 	at
> 	io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> 	at
> 	io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> 	at
> 	io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> 	at
> 	io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> 	at
> 	io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> 	at
> 	io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> 	at
> 	io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at
> 	io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at
> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at
> 	io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> 	at
> 	io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at
> 	io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at
> 	io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> 	at
> 	io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 	at
> 	io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at
> 	io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at
> 	io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at
> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at
> 	org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at
> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at
> 	io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at
> 	io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	at
> 	java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at
> 	java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7

--
Michal Karm Babacek
    ? JBoss QE    
Red Hat Czech | GMT+2

? +420 737 778 560 (cell)
? +420 532 294 547 (?forwarded?)
freenode: #wildfly #mod_cluster #fedora-devel
? http://modcluster.io ? karm at redhat.com


From sdouglas at redhat.com  Thu May 12 09:46:43 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 12 May 2016 23:46:43 +1000
Subject: [undertow-dev] java.lang.IllegalStateException: UT000124:
 renegotiation timed out
In-Reply-To: <377C47DC-20DD-401D-BE1F-2CAEC75B3219@primacinema.com>
References: <377C47DC-20DD-401D-BE1F-2CAEC75B3219@primacinema.com>
Message-ID: <CAD+L2cyjcS8SEM7=29mzeZeyzmM2OLvkd0j4N2_PBAm-y+RrJQ@mail.gmail.com>

Can you update to the latest version of undertow? I think there have been a
couple of changes in this area

Stuart
On 11 May 2016 11:40 PM, "Brian Call" <brian.call at primacinema.com> wrote:

> Hi Guys,
>
> First off, I?m trying to figure out whether or not I?m dealing with a bug
> or a user error on this one, so my apologies for spamming everyone. There
> is scant information pertaining to this error anywhere that I found as
> google only returned a single result, and that was to the messages class
> containing the message code.
>
> I?m seeing this exception on TLS negotiation using client certs and I just
> can?t figure out what?s being renegotiated or why there would be a timeout.
> It?s all happening in milliseconds so I?m very confused, especially since
> it seems to happen intermittently and under varying circumstances. I?ve
> examined the source code for the wildly-10 version undertow that I?m using
> and I just can?t figure it out. Any hints in the right direction would be
> greatly appreciated.
>
> Blessings,
> Brian
>
> Here?s the stack trace:
>
> 2016-05-11 20:27:51,766 ERROR [io.undertow.request] (default task-7)
> UT005023: Exception handling request to /ppi/whoami:
> java.lang.IllegalStateException: UT000124: renegotiation timed out
> at
> io.undertow.server.ConnectionSSLSessionInfo.renegotiateNoRequest(ConnectionSSLSessionInfo.java:175)
> at
> io.undertow.server.ConnectionSSLSessionInfo.renegotiate(ConnectionSSLSessionInfo.java:89)
> at
> io.undertow.security.impl.ClientCertAuthenticationMechanism.getPeerCertificates(ClientCertAuthenticationMechanism.java:125)
> at
> io.undertow.security.impl.ClientCertAuthenticationMechanism.authenticate(ClientCertAuthenticationMechanism.java:92)
> at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at
> io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at
> io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at
> io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at
> io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at
> io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at
> io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> at
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at
> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160512/a405d369/attachment.html 

From brian.call at primacinema.com  Thu May 12 13:49:52 2016
From: brian.call at primacinema.com (Brian Call)
Date: Thu, 12 May 2016 10:49:52 -0700
Subject: [undertow-dev] java.lang.IllegalStateException: UT000124:
	renegotiation timed out
In-Reply-To: <CAD+L2cyjcS8SEM7=29mzeZeyzmM2OLvkd0j4N2_PBAm-y+RrJQ@mail.gmail.com>
References: <377C47DC-20DD-401D-BE1F-2CAEC75B3219@primacinema.com>
	<CAD+L2cyjcS8SEM7=29mzeZeyzmM2OLvkd0j4N2_PBAm-y+RrJQ@mail.gmail.com>
Message-ID: <1FDD22AF-FFDF-4C90-B19E-7BC19FB2E7BF@primacinema.com>

Thank you guys for getting back to me!

I?ve seen the latest source code and it appears vastly different than the version deployed with wildly 10. . I?ll first enable the SSL debug logging so I can post some additional information. Then I?ll do the upgrade. 

I?ll get back to you guys here shortly. 

Blessings,
Brian 

> On May 12, 2016, at 6:46 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
> 
> Can you update to the latest version of undertow? I think there have been a couple of changes in this area
> 
> Stuart
> 
> On 11 May 2016 11:40 PM, "Brian Call" <brian.call at primacinema.com <mailto:brian.call at primacinema.com>> wrote:
> Hi Guys,
> 
> First off, I?m trying to figure out whether or not I?m dealing with a bug or a user error on this one, so my apologies for spamming everyone. There is scant information pertaining to this error anywhere that I found as google only returned a single result, and that was to the messages class containing the message code. 
> 
> I?m seeing this exception on TLS negotiation using client certs and I just can?t figure out what?s being renegotiated or why there would be a timeout. It?s all happening in milliseconds so I?m very confused, especially since it seems to happen intermittently and under varying circumstances. I?ve examined the source code for the wildly-10 version undertow that I?m using and I just can?t figure it out. Any hints in the right direction would be greatly appreciated. 
> 
> Blessings,
> Brian
> 
> Here?s the stack trace:
> 
> 2016-05-11 20:27:51,766 ERROR [io.undertow.request] (default task-7) UT005023: Exception handling request to /ppi/whoami: java.lang.IllegalStateException: UT000124: renegotiation timed out
> 	at io.undertow.server.ConnectionSSLSessionInfo.renegotiateNoRequest(ConnectionSSLSessionInfo.java:175)
> 	at io.undertow.server.ConnectionSSLSessionInfo.renegotiate(ConnectionSSLSessionInfo.java:89)
> 	at io.undertow.security.impl.ClientCertAuthenticationMechanism.getPeerCertificates(ClientCertAuthenticationMechanism.java:125)
> 	at io.undertow.security.impl.ClientCertAuthenticationMechanism.authenticate(ClientCertAuthenticationMechanism.java:92)
> 	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> 	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> 	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> 	at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> 	at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> 	at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> 	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> 	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> 	at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at java.lang.Thread.run(Thread.java:745)
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org <mailto:undertow-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/undertow-dev <https://lists.jboss.org/mailman/listinfo/undertow-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160512/9df5a692/attachment-0001.html 

From oliver at analyticspot.com  Thu May 12 14:13:11 2016
From: oliver at analyticspot.com (Oliver Dain)
Date: Thu, 12 May 2016 18:13:11 +0000
Subject: [undertow-dev] receiveFullBytes callbacks never called
In-Reply-To: <CAD+L2cxwQ83q-ec8a1KCXEDN7z+E9=FgW-A_Q+YmhrufqO72NA@mail.gmail.com>
References: <CACSC6EUzQRM6W0kaRcSyt8iSu993GZbWBX7gX2_GVre1PvD4qg@mail.gmail.com>
	<CAD+L2cxwQ83q-ec8a1KCXEDN7z+E9=FgW-A_Q+YmhrufqO72NA@mail.gmail.com>
Message-ID: <CACSC6EV-mB7F=Gc84RXO0odaAD+g=R4t8D+P8NAC7GAmtxcKeA@mail.gmail.com>

Done: https://issues.jboss.org/browse/UNDERTOW-710

On Thu, May 12, 2016 at 5:21 AM Stuart Douglas <sdouglas at redhat.com> wrote:

> This sounds like a bug, can you file a JIRA? I am traveling at the
> moment but I will investigate when I get back.
>
> Stuart
>
> On Wed, May 11, 2016 at 10:54 AM, Oliver Dain <oliver at analyticspot.com>
> wrote:
> > I've got a case where I can call receiveFullBytes but neither the success
> > nor the error handler is ever called. My code looks like this:
> >
> > public static CompletableFuture<ByteSource>
> > getCompleteBody(HttpServerExchange exchange) {
> >   log.debug("In getCompleteBody.");
> >   CompletableFuture<ByteSource> finalResult = new CompletableFuture<>();
> >   try {
> >     log.debug("Calling receiveFullBytes.");
> >     exchange.getRequestReceiver().receiveFullBytes(
> >         // Success case.
> >         (HttpServerExchange excng, byte[] bytes) -> {
> >           log.debug("getFullBytes completed with success.");
> >           finalResult.complete(ByteSource.wrap(bytes));
> >         },
> >
> >         // Error case
> >         (HttpServerExchange exchng, IOException t) -> {
> >           log.warn("getFullBytes completed with an error:", t);
> >           finalResult.completeExceptionally(t);
> >         }
> >     );
> >   } catch (Throwable t) {
> >     log.warn("receiveFullBytes threw an exception:", t);
> >     finalResult.completeExceptionally(t);
> >   }
> >
> >   return finalResult;
> > }
> >
> > I've got a unit test that opens a socket, starts sending data, and then,
> > intentionally throws an exception. The test then ensures that the
> > CompletableFuture above completes with an exception. Except, it never
> > completes.. the test just hangs forever. You can see that the
> > "log.debug("Calling receiveFullBytes.")" line does get called and that
> the
> > neither of the log lines in either callback is ever called. The full test
> > looks like this:
> >
> > @Test
> > public void getCompleteBodyCompletesWithExceptionOnBodyFailure() throws
> > Exception {
> >   AtomicBoolean futureRedeemedWithError = new AtomicBoolean(false);
> >   CountDownLatch waitForInputToFail = new CountDownLatch(1);
> >
> >   HttpHandler handler = new HttpHandler() {
> >     @Override
> >     public void handleRequest(HttpServerExchange exchange) throws
> Exception
> > {
> >       log.info("Handler called.");
> >       exchange.dispatch();
> >       log.info("Calling getCompleteBody");
> >       UndertowUtils.getCompleteBody(exchange).exceptionally((Throwable
> t) ->
> > {
> >         log.debug("As expected, received an exception:", t);
> >         futureRedeemedWithError.set(true);
> >         waitForInputToFail.countDown();
> >         return null;
> >       });
> >     }
> >   };
> >   UndertowTestUtils.RunningServer server =
> > UndertowTestUtils.startUndertowOnFreePort(handler);
> >
> >   // A Body() implementation that will return a few chunks of data but
> the
> > fail
> >   Body failingRequestBody = new Body() {
> >     private AtomicInteger readCalls = new AtomicInteger(0);
> >     @Override
> >     public long getContentLength() {
> >       return 1000;
> >     }
> >
> >     @Override
> >     public long read(ByteBuffer buffer) throws IOException {
> >       if (readCalls.getAndIncrement() < 2) {
> >         byte[] toSend = "some data".getBytes(Charsets.UTF_8);
> >         buffer.put(toSend);
> >         return toSend.length;
> >       } else {
> >         throw new RuntimeException("Fake error on sending data.");
> >       }
> >     }
> >
> >     @Override
> >     public void close() throws IOException {
> >     }
> >   };
> >
> >   // A body generator using the above, busted Body.
> >   BodyGenerator failingBodyGenerator = new BodyGenerator() {
> >     @Override
> >     public Body createBody() throws IOException {
> >       return failingRequestBody;
> >     }
> >   };
> >
> >   // This will start sending data so our handler gets invoked but it will
> > then fail partway through.
> >   SimpleAsyncHttpClient client = new SimpleAsyncHttpClient.Builder()
> >       .setUrl(String.format("http://localhost:%s", server.getPort()))
> >       .build();
> >
> >   client.post(failingBodyGenerator);
> >
> >
> >   // Test hangs here forever
> >   waitForInputToFail.await();
> >
> >   assertThat(futureRedeemedWithError.get()).isTrue();
> > }
> >
> >
> > This feels like a bug. I'd expect the contract of "receiveFullBytes" to
> be
> > that either the success or failure handler gets called exactly once. Is
> this
> > a bug? If not, what am I doing wrong?
> >
> > Thanks,
> >
> > Oliver
> >
> > --
> > CTO, Analytic Spot
> > 44 West Broadway #222
> > Eugene, OR 97401
> > analyticspot.com ? 425-296-6556
> > www.linkedin.com/in/oliverdain
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-- 
CTO, Analytic Spot
44 West Broadway #222
Eugene, OR 97401
analyticspot.com ? 425-296-6556
www.linkedin.com/in/oliverdain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160512/96d1ebab/attachment.html 

From matt at matthicks.com  Wed May 18 13:37:16 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 18 May 2016 17:37:16 +0000
Subject: [undertow-dev] Proxy Server with WebSocket Support?
In-Reply-To: <1463592923659-de2efa51-4211a954-466e40a8@mixmax.com>
References: <1463592923659-de2efa51-4211a954-466e40a8@mixmax.com>
Message-ID: <1463593036438-ff0b10bf-bedb60f7-2a44bec1@mixmax.com>

How difficult would it be to write a proxy server that proxies to a web server
that takes advantage of WebSockets? I've been looking through the documentation
and though there is easy access to proxying and direct support for WebSockets, I
can't see a clear path to integrate the two to create a proxy server that
proxies to a web server that utilizes WebSockets.
Any examples, tutorials, links, sample code, etc. is greatly appreciated.
Thanks,
Matt Hicks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160518/9d837d61/attachment.html 

From sdouglas at redhat.com  Wed May 18 13:46:04 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 18 May 2016 20:46:04 +0300
Subject: [undertow-dev] Proxy Server with WebSocket Support?
In-Reply-To: <1463593036438-ff0b10bf-bedb60f7-2a44bec1@mixmax.com>
References: <1463592923659-de2efa51-4211a954-466e40a8@mixmax.com>
	<1463593036438-ff0b10bf-bedb60f7-2a44bec1@mixmax.com>
Message-ID: <CAD+L2cyN4QsPnoH8QG=pJ5Ocvm3sD7rnjC+wWXGzg2yVm+eNoA@mail.gmail.com>

It should just work automatically.

On 18 May 2016 19:37, "Hicks, Matt" <matt at matthicks.com> wrote:
>
>
> How difficult would it be to write a proxy server that proxies to a web
server that takes advantage of WebSockets?  I've been looking through the
documentation and though there is easy access to proxying and direct
support for WebSockets, I can't see a clear path to integrate the two to
create a proxy server that proxies to a web server that utilizes WebSockets.
>
> Any examples, tutorials, links, sample code, etc. is greatly appreciated.
>
> Thanks,
>
> Matt Hicks
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160518/24502f75/attachment-0001.html 

From matt at matthicks.com  Wed May 18 14:36:56 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 18 May 2016 18:36:56 +0000
Subject: [undertow-dev] Proxy Server with WebSocket Support?
In-Reply-To: <CAD+L2cyN4QsPnoH8QG=pJ5Ocvm3sD7rnjC+wWXGzg2yVm+eNoA@mail.gmail.com>
References: <1463592923659-de2efa51-4211a954-466e40a8@mixmax.com>
	<1463593036438-ff0b10bf-bedb60f7-2a44bec1@mixmax.com>
	<CAD+L2cyN4QsPnoH8QG=pJ5Ocvm3sD7rnjC+wWXGzg2yVm+eNoA@mail.gmail.com>
Message-ID: <1463596616972-c43107a6-b95fa259-d6cbaad1@mixmax.com>

It seems to partially work, but when I actually try to send a message through
the WebSocket the connection dies.
Here's my code:
https://gist.github.com/darkfrog26/ce90a08a8bd58e674e7faed84d021db8
Seems pretty simple and straight-forward, but perhaps I have to set something
special for WebSockets to work? On Wed, May 18, 2016 at 12:46 PM Stuart Douglas <sdouglas at redhat.com> wrote:
It should just work automatically.



On 18 May 2016 19:37, "Hicks, Matt" < matt at matthicks.com > wrote:
>
>
> How difficult would it be to write a proxy server that proxies to a web server
that takes advantage of WebSockets? I've been looking through the documentation
and though there is easy access to proxying and direct support for WebSockets, I
can't see a clear path to integrate the two to create a proxy server that
proxies to a web server that utilizes WebSockets.
>
> Any examples, tutorials, links, sample code, etc. is greatly appreciated.
>
> Thanks,
>
> Matt Hicks
>


> ______________________________ _________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/ mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160518/10125868/attachment.html 

From matt at matthicks.com  Thu May 19 10:27:14 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Thu, 19 May 2016 14:27:14 +0000
Subject: [undertow-dev] Proxy Server with WebSocket Support?
In-Reply-To: <1463596616972-c43107a6-b95fa259-d6cbaad1@mixmax.com>
References: <1463592923659-de2efa51-4211a954-466e40a8@mixmax.com>
	<1463593036438-ff0b10bf-bedb60f7-2a44bec1@mixmax.com>
	<CAD+L2cyN4QsPnoH8QG=pJ5Ocvm3sD7rnjC+wWXGzg2yVm+eNoA@mail.gmail.com>
	<1463596616972-c43107a6-b95fa259-d6cbaad1@mixmax.com>
Message-ID: <1463668034643-20455296-da32adeb-765cb3f9@mixmax.com>

Is this simply not possible to do? On Wed, May 18, 2016 at 1:36 PM Hicks, Matt <matt at matthicks.com> wrote:
It seems to partially work, but when I actually try to send a message through
the WebSocket the connection dies.
Here's my code: https://gist.github.com/ darkfrog26/ ce90a08a8bd58e674e7faed84d021d b8
Seems pretty simple and straight-forward, but perhaps I have to set something
special for WebSockets to work? On Wed, May 18, 2016 at 12:46 PM Stuart Douglas < sdouglas at redhat.com > wrote:
It should just work automatically.



On 18 May 2016 19:37, "Hicks, Matt" < matt at matthicks.com > wrote:
>
>
> How difficult would it be to write a proxy server that proxies to a web server
that takes advantage of WebSockets? I've been looking through the documentation
and though there is easy access to proxying and direct support for WebSockets, I
can't see a clear path to integrate the two to create a proxy server that
proxies to a web server that utilizes WebSockets.
>
> Any examples, tutorials, links, sample code, etc. is greatly appreciated.
>
> Thanks,
>
> Matt Hicks
>


> ______________________________ _________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailma n/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160519/ceab5c1c/attachment.html 

From matt at matthicks.com  Thu May 19 19:18:05 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Thu, 19 May 2016 23:18:05 +0000
Subject: [undertow-dev] Proxying WebSockets
Message-ID: <1463699885667-276918b3-af1e0ae0-7dbb83cf@mixmax.com>

I did some additional testing with 2.0.0.Alpha1 and got the exact same results.
If there is some way to accomplish proper proxying with Undertow I'm not seeing
it.
Should I file a bug report?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160519/11ee53eb/attachment-0001.html 

From sdouglas at redhat.com  Mon May 23 03:48:23 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 23 May 2016 09:48:23 +0200
Subject: [undertow-dev] Proxying WebSockets
In-Reply-To: <1463699885667-276918b3-af1e0ae0-7dbb83cf@mixmax.com>
References: <1463699885667-276918b3-af1e0ae0-7dbb83cf@mixmax.com>
Message-ID: <CAD+L2cxGihMokSPGqKaKRbsAKZN=LSv8=DRWYLfUB3VuFBC_Gw@mail.gmail.com>

When you say it does not work exactly what behaviour are you seeing? Does
the connection get established? If it gets established and then fails which
side drops the connection?

We have extensive tests for this in the test suite, as web socket tests are
run through the proxy server, we need more info to see why it is not
working for you.

Stuart

On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt <matt at matthicks.com> wrote:

> I did some additional testing with 2.0.0.Alpha1 and got the exact same
> results.  If there is some way to accomplish proper proxying with Undertow
> I'm not seeing it.
>
> Should I file a bug report?
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160523/ac73f0f4/attachment.html 

From matt at matthicks.com  Mon May 23 09:24:10 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Mon, 23 May 2016 13:24:10 +0000
Subject: [undertow-dev] Proxying WebSockets
In-Reply-To: <CAD+L2cxGihMokSPGqKaKRbsAKZN=LSv8=DRWYLfUB3VuFBC_Gw@mail.gmail.com>
References: <1463699885667-276918b3-af1e0ae0-7dbb83cf@mixmax.com>
	<CAD+L2cxGihMokSPGqKaKRbsAKZN=LSv8=DRWYLfUB3VuFBC_Gw@mail.gmail.com>
Message-ID: <1464009850815-47dfbe75-fbce15a5-9a491c1d@mixmax.com>

Stuart, I created a ticket with all the information I know to provide:

[UNDERTOW-714] Broken WebSocket Proxying Support - JBoss Issue Tracker I have been attempting to write a test proxy server to proxy explicitly to
another server. issues.jboss.org

I'm not positive which side is closing the connection, but looking at the
JavaScript console it's showing the connection is being closed almost
immediately after any message is sent from the browser to the server.
On Mon, May 23, 2016 at 2:48 AM Stuart Douglas <sdouglas at redhat.com> wrote:
When you say it does not work exactly what behaviour are you seeing? Does the
connection get established? If it gets established and then fails which side
drops the connection?

We have extensive tests for this in the test suite, as web socket tests are run
through the proxy server, we need more info to see why it is not working for
you.

Stuart

On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt < matt at matthicks.com > wrote:
I did some additional testing with 2.0.0.Alpha1 and got the exact same results.
If there is some way to accomplish proper proxying with Undertow I'm not seeing
it.
Should I file a bug report?

______________________________ _________________
undertow-dev mailing list
undertow-dev at lists.jboss.org
https://lists.jboss.org/ mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160523/0f80d9c2/attachment.html 

From sdouglas at redhat.com  Mon May 23 12:17:37 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 23 May 2016 18:17:37 +0200
Subject: [undertow-dev] Proxying WebSockets
In-Reply-To: <1464009850815-47dfbe75-fbce15a5-9a491c1d@mixmax.com>
References: <1463699885667-276918b3-af1e0ae0-7dbb83cf@mixmax.com>
	<CAD+L2cxGihMokSPGqKaKRbsAKZN=LSv8=DRWYLfUB3VuFBC_Gw@mail.gmail.com>
	<1464009850815-47dfbe75-fbce15a5-9a491c1d@mixmax.com>
Message-ID: <CAD+L2czgA0-0nFsouYJHa+SFcM9gbAumOSjWvs7NgSDFOprnYQ@mail.gmail.com>

Do you have a reproduce I can run (complete with JS etc so I can see
exactly what is going on)?

Stuart

On Mon, May 23, 2016 at 3:24 PM, Hicks, Matt <matt at matthicks.com> wrote:

> Stuart, I created a ticket with all the information I know to provide:
>
>
> [UNDERTOW-714] Broken WebSocket Proxying Support - JBoss Issue Tracker
> <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t>
> I have been attempting to write a test proxy server to proxy explicitly to
> another server. <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t>
> issues.jboss.org <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t> [image:
> Mixmax] <https://mixmax.com/r/rExsBBgirNC89QPSv>
>
>
> I'm not positive which side is closing the connection, but looking at the
> JavaScript console it's showing the connection is being closed almost
> immediately after any message is sent from the browser to the server.
>
> On Mon, May 23, 2016 at 2:48 AM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> When you say it does not work exactly what behaviour are you seeing? Does
>> the connection get established? If it gets established and then fails which
>> side drops the connection?
>>
>> We have extensive tests for this in the test suite, as web socket tests
>> are run through the proxy server, we need more info to see why it is not
>> working for you.
>>
>> Stuart
>>
>> On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt <matt at matthicks.com> wrote:
>>
>>> I did some additional testing with 2.0.0.Alpha1 and got the exact same
>>> results.  If there is some way to accomplish proper proxying with Undertow
>>> I'm not seeing it.
>>>
>>> Should I file a bug report?
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160523/740e2754/attachment-0001.html 

From matt at matthicks.com  Mon May 23 12:29:17 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Mon, 23 May 2016 16:29:17 +0000
Subject: [undertow-dev] Proxying WebSockets
In-Reply-To: <CAD+L2czgA0-0nFsouYJHa+SFcM9gbAumOSjWvs7NgSDFOprnYQ@mail.gmail.com>
References: <1463699885667-276918b3-af1e0ae0-7dbb83cf@mixmax.com>
	<CAD+L2cxGihMokSPGqKaKRbsAKZN=LSv8=DRWYLfUB3VuFBC_Gw@mail.gmail.com>
	<1464009850815-47dfbe75-fbce15a5-9a491c1d@mixmax.com>
	<CAD+L2czgA0-0nFsouYJHa+SFcM9gbAumOSjWvs7NgSDFOprnYQ@mail.gmail.com>
Message-ID: <CAFeDf19zzftPoyGek=vS3_=Ox5Y33qm_NKOvnXwFwjGu5H4p+Q@mail.gmail.com>

Yes, I do. You can run the example code and it runs against hyperscala.org.
If you go to http://hyperscala.org/example/realtime/chat.html or
http://localhost:8080/example/realtime/chat.html you can test the Chat
example that uses WebSockets.  If you connect directly it works fine, if
you connect via the Proxy it doesn't.

On Mon, May 23, 2016, 11:17 AM Stuart Douglas <sdouglas at redhat.com> wrote:

> Do you have a reproduce I can run (complete with JS etc so I can see
> exactly what is going on)?
>
> Stuart
>
> On Mon, May 23, 2016 at 3:24 PM, Hicks, Matt <matt at matthicks.com> wrote:
>
>> Stuart, I created a ticket with all the information I know to provide:
>>
>>
>> [UNDERTOW-714] Broken WebSocket Proxying Support - JBoss Issue Tracker
>> <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t>
>> I have been attempting to write a test proxy server to proxy explicitly
>> to another server. <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t>
>> issues.jboss.org <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t> [image:
>> Mixmax] <https://mixmax.com/r/rExsBBgirNC89QPSv>
>>
>>
>> I'm not positive which side is closing the connection, but looking at the
>> JavaScript console it's showing the connection is being closed almost
>> immediately after any message is sent from the browser to the server.
>>
>> On Mon, May 23, 2016 at 2:48 AM Stuart Douglas <sdouglas at redhat.com>
>> wrote:
>>
>>> When you say it does not work exactly what behaviour are you seeing?
>>> Does the connection get established? If it gets established and then fails
>>> which side drops the connection?
>>>
>>> We have extensive tests for this in the test suite, as web socket tests
>>> are run through the proxy server, we need more info to see why it is not
>>> working for you.
>>>
>>> Stuart
>>>
>>> On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt <matt at matthicks.com> wrote:
>>>
>>>> I did some additional testing with 2.0.0.Alpha1 and got the exact same
>>>> results.  If there is some way to accomplish proper proxying with Undertow
>>>> I'm not seeing it.
>>>>
>>>> Should I file a bug report?
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160523/b45c5bc5/attachment.html 

From matt at matthicks.com  Wed May 25 09:54:31 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 25 May 2016 13:54:31 +0000
Subject: [undertow-dev] Proxying WebSockets
Message-ID: <1464184472315-882e71d7-331eeff4-505beb4b@mixmax.com>

Stuart, is there anything else you need from me to look into this further?
On Mon, May 23, 2016 at 11:29 AM Hicks, Matt <matt at matthicks.com> wrote:
Yes, I do. You can run the example code and it runs against hyperscala.org . If you go to http://hyperscala.org/ example/realtime/chat.html or http://localhost:8080/example/ realtime/chat.html you can test the Chat example that uses WebSockets. If you connect directly it
works fine, if you connect via the Proxy it doesn't.


On Mon, May 23, 2016, 11:17 AM Stuart Douglas < sdouglas at redhat.com > wrote:
Do you have a reproduce I can run (complete with JS etc so I can see exactly
what is going on)?

Stuart

On Mon, May 23, 2016 at 3:24 PM, Hicks, Matt < matt at matthicks.com > wrote:
Stuart, I created a ticket with all the information I know to provide:

[UNDERTOW-714] Broken WebSocket Proxying Support - JBoss Issue Tracker I have been attempting to write a test proxy server to proxy explicitly to
another server. issues.jboss.org

I'm not positive which side is closing the connection, but looking at the
JavaScript console it's showing the connection is being closed almost
immediately after any message is sent from the browser to the server.
On Mon, May 23, 2016 at 2:48 AM Stuart Douglas < sdouglas at redhat.com > wrote:
When you say it does not work exactly what behaviour are you seeing? Does the
connection get established? If it gets established and then fails which side
drops the connection?

We have extensive tests for this in the test suite, as web socket tests are run
through the proxy server, we need more info to see why it is not working for
you.

Stuart

On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt < matt at matthicks.com > wrote:
I did some additional testing with 2.0.0.Alpha1 and got the exact same results.
If there is some way to accomplish proper proxying with Undertow I'm not seeing
it.
Should I file a bug report?

______________________________ _________________
undertow-dev mailing list
undertow-dev at lists.jboss.org
https://lists.jboss.org/ mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160525/c09c2dd1/attachment-0001.html 

From sdouglas at redhat.com  Wed May 25 10:39:05 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 25 May 2016 16:39:05 +0200
Subject: [undertow-dev] Proxying WebSockets
In-Reply-To: <1464184472315-882e71d7-331eeff4-505beb4b@mixmax.com>
References: <1464184472315-882e71d7-331eeff4-505beb4b@mixmax.com>
Message-ID: <CAD+L2czV_CyKLo+5JGH3vr+0FnnzGLLcvCHVqFzKycQ37jmy4Q@mail.gmail.com>

I am traveling and in meetings all week, I will look into it next week.

Stuart

On Wed, May 25, 2016 at 3:54 PM, Hicks, Matt <matt at matthicks.com> wrote:

> Stuart, is there anything else you need from me to look into this further?
>
> On Mon, May 23, 2016 at 11:29 AM Hicks, Matt <matt at matthicks.com> wrote:
>
>> Yes, I do. You can run the example code and it runs against
>> hyperscala.org.  If you go to
>> http://hyperscala.org/example/realtime/chat.html or
>> http://localhost:8080/example/realtime/chat.html you can test the Chat
>> example that uses WebSockets.  If you connect directly it works fine, if
>> you connect via the Proxy it doesn't.
>>
>> On Mon, May 23, 2016, 11:17 AM Stuart Douglas <sdouglas at redhat.com>
>> wrote:
>>
>>> Do you have a reproduce I can run (complete with JS etc so I can see
>>> exactly what is going on)?
>>>
>>> Stuart
>>>
>>> On Mon, May 23, 2016 at 3:24 PM, Hicks, Matt <matt at matthicks.com> wrote:
>>>
>>>> Stuart, I created a ticket with all the information I know to provide:
>>>>
>>>>
>>>> [UNDERTOW-714] Broken WebSocket Proxying Support - JBoss Issue Tracker
>>>> <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t>
>>>> I have been attempting to write a test proxy server to proxy explicitly
>>>> to another server.
>>>> <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t>
>>>> issues.jboss.org <https://issues.jboss.org/browse/UNDERTOW-714?_sscc=t> [image:
>>>> Mixmax] <https://mixmax.com/r/rExsBBgirNC89QPSv>
>>>>
>>>>
>>>> I'm not positive which side is closing the connection, but looking at
>>>> the JavaScript console it's showing the connection is being closed almost
>>>> immediately after any message is sent from the browser to the server.
>>>>
>>>> On Mon, May 23, 2016 at 2:48 AM Stuart Douglas <sdouglas at redhat.com>
>>>> wrote:
>>>>
>>>>> When you say it does not work exactly what behaviour are you seeing?
>>>>> Does the connection get established? If it gets established and then fails
>>>>> which side drops the connection?
>>>>>
>>>>> We have extensive tests for this in the test suite, as web socket
>>>>> tests are run through the proxy server, we need more info to see why it is
>>>>> not working for you.
>>>>>
>>>>> Stuart
>>>>>
>>>>> On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt <matt at matthicks.com>
>>>>> wrote:
>>>>>
>>>>>> I did some additional testing with 2.0.0.Alpha1 and got the exact
>>>>>> same results.  If there is some way to accomplish proper proxying with
>>>>>> Undertow I'm not seeing it.
>>>>>>
>>>>>> Should I file a bug report?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>>
>>>>>
>>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160525/334a7579/attachment.html 

From matt at matthicks.com  Wed May 25 10:50:34 2016
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 25 May 2016 14:50:34 +0000
Subject: [undertow-dev] Proxying WebSockets
In-Reply-To: <CAD+L2czV_CyKLo+5JGH3vr+0FnnzGLLcvCHVqFzKycQ37jmy4Q@mail.gmail.com>
References: <1464184472315-882e71d7-331eeff4-505beb4b@mixmax.com>
	<CAD+L2czV_CyKLo+5JGH3vr+0FnnzGLLcvCHVqFzKycQ37jmy4Q@mail.gmail.com>
Message-ID: <1464187834745-847ca1d4-12abd8da-ebedecb3@mixmax.com>

Okay, thank you.
On Wed, May 25, 2016 at 9:39 AM Stuart Douglas <sdouglas at redhat.com> wrote:
I am traveling and in meetings all week, I will look into it next week.

Stuart

On Wed, May 25, 2016 at 3:54 PM, Hicks, Matt < matt at matthicks.com > wrote:
Stuart, is there anything else you need from me to look into this further?
On Mon, May 23, 2016 at 11:29 AM Hicks, Matt < matt at matthicks.com > wrote:
Yes, I do. You can run the example code and it runs against hyperscala.org . If you go to http://hyperscala.org/ example/realtime/chat.html or http://localhost:8080/example/ realtime/chat.html you can test the Chat example that uses WebSockets. If you connect directly it
works fine, if you connect via the Proxy it doesn't.


On Mon, May 23, 2016, 11:17 AM Stuart Douglas < sdouglas at redhat.com > wrote:
Do you have a reproduce I can run (complete with JS etc so I can see exactly
what is going on)?

Stuart

On Mon, May 23, 2016 at 3:24 PM, Hicks, Matt < matt at matthicks.com > wrote:
Stuart, I created a ticket with all the information I know to provide:

[UNDERTOW-714] Broken WebSocket Proxying Support - JBoss Issue Tracker I have been attempting to write a test proxy server to proxy explicitly to
another server. issues.jboss.org

I'm not positive which side is closing the connection, but looking at the
JavaScript console it's showing the connection is being closed almost
immediately after any message is sent from the browser to the server.
On Mon, May 23, 2016 at 2:48 AM Stuart Douglas < sdouglas at redhat.com > wrote:
When you say it does not work exactly what behaviour are you seeing? Does the
connection get established? If it gets established and then fails which side
drops the connection?

We have extensive tests for this in the test suite, as web socket tests are run
through the proxy server, we need more info to see why it is not working for
you.

Stuart

On Fri, May 20, 2016 at 1:18 AM, Hicks, Matt < matt at matthicks.com > wrote:
I did some additional testing with 2.0.0.Alpha1 and got the exact same results.
If there is some way to accomplish proper proxying with Undertow I'm not seeing
it.
Should I file a bug report?

______________________________ _________________
undertow-dev mailing list
undertow-dev at lists.jboss.org
https://lists.jboss.org/ mailman/listinfo/undertow-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160525/21e85d6f/attachment-0001.html 

From sven at kubiak.me  Sun May 29 09:12:08 2016
From: sven at kubiak.me (Sven Kubiak)
Date: Sun, 29 May 2016 13:12:08 +0000
Subject: [undertow-dev] Undertow statistics
Message-ID: <1464527529776.90719@kubiak.me>

I saw that Undetow can collect statistics. I have set the appropriate Untertow option (ENABLE_STATISTICS). However, how do I access the raw statistic data programmatically??


Cheers,

Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160529/81fb6e79/attachment.html 

From sdouglas at redhat.com  Mon May 30 03:35:21 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 30 May 2016 09:35:21 +0200
Subject: [undertow-dev] Undertow statistics
In-Reply-To: <1464527529776.90719@kubiak.me>
References: <1464527529776.90719@kubiak.me>
Message-ID: <CAD+L2cwCFOYAdkDR99C+R0QN_WZDUYFy47_bCmoXtim8y4ZzAg@mail.gmail.com>

It looks like due to an oversight there is no easy way to get access
to this via the Undertow builder.

The relevant call that is used in Wildfly is
io.undertow.server.OpenListener#getConnectorStatistics, however there
is no way to access this via the Undertow builder. I have created
https://issues.jboss.org/browse/UNDERTOW-718

Stuart

On Sun, May 29, 2016 at 3:12 PM, Sven Kubiak <sven at kubiak.me> wrote:
> I saw that Undetow can collect statistics. I have set the appropriate
> Untertow option (ENABLE_STATISTICS). However, how do I access the raw
> statistic data programmatically?
>
>
> Cheers,
>
> Sven
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From electrotype at gmail.com  Mon May 30 22:41:51 2016
From: electrotype at gmail.com (electrotype)
Date: Mon, 30 May 2016 22:41:51 -0400
Subject: [undertow-dev] Websocket messages : should we start a new Thread to
	handle them?
Message-ID: <5270dbcf-bc67-79db-d88c-2c913397211d@gmail.com>

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 /Websocket//s/ 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160530/2a89e0df/attachment.html 

From sdouglas at redhat.com  Mon May 30 23:15:03 2016
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 31 May 2016 05:15:03 +0200
Subject: [undertow-dev] Websocket messages : should we start a new
 Thread to handle them?
In-Reply-To: <5270dbcf-bc67-79db-d88c-2c913397211d@gmail.com>
References: <5270dbcf-bc67-79db-d88c-2c913397211d@gmail.com>
Message-ID: <CAD+L2cyKMT_WSiKfNh=YkZ0Onb05K35q5rKcNEPxaQAQ7hEwtQ@mail.gmail.com>

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

From electrotype at gmail.com  Tue May 31 05:09:24 2016
From: electrotype at gmail.com (electrotype)
Date: Tue, 31 May 2016 05:09:24 -0400
Subject: [undertow-dev] Websocket messages : should we start a new
 Thread to handle them?
In-Reply-To: <CAD+L2cyKMT_WSiKfNh=YkZ0Onb05K35q5rKcNEPxaQAQ7hEwtQ@mail.gmail.com>
References: <5270dbcf-bc67-79db-d88c-2c913397211d@gmail.com>
	<CAD+L2cyKMT_WSiKfNh=YkZ0Onb05K35q5rKcNEPxaQAQ7hEwtQ@mail.gmail.com>
Message-ID: <d5fd8053-8a02-acc6-73b5-be35085973bc@gmail.com>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20160531/0b5e843f/attachment-0001.html