Re: isAsyncStarted=true on ERROR dispatch

[Rossen Stoyanchev]

On Wed, Jul 13, 2016 at 12:46 PM, Rémy Maucherat  wrote:

> 2016-07-13 14:00 GMT+02:00 Violeta Georgieva :
>
> > Hi,
> >
> > I think the following part of the specification is important:
> >
> > "
> > In the event that an asynchronous operation times out, the container must
> > run through the following steps:
> > - Invoke the AsyncListener.onTimeout method on all the AsyncListener
> > instances registered with the ServletRequest on which the asynchronous
> > operation was initiated.
> > - If none of the listeners called AsyncContext.complete() or any of the
> > AsyncContext.dispatch methods, perform an error dispatch with a status
> code
> > equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR.
> > - If no matching error page was found, or the error page did not call
> > AsyncContext.complete() or any of the AsyncContext.dispatch methods, the
> > container MUST call AsyncContext.complete().
> > "
> >
> > So isAsyncStarted returns true when in the error page and the error page
> > should call AsyncContext.complete.
> >
> > What do you think?
> >
> > It makes more sense to me than changing the behavior at this point. I
> will
> probably veto any attempt to change again the behavior until it is proven
> beyond any doubt that it is wrong.
>


No need to yield veto power. I'm only asking questions :)

It sounds like the change is not intentional but it's unlikely to go back
either. For what it's worth in Jetty a call to startAsync from an ERROR
dispatch does work and keeps the request going. That said I don't know if
that's intentional or not. At any rate thanks for your comments.

Re: isAsyncStarted=true on ERROR dispatch

[Rossen Stoyanchev]

On Wed, Jul 13, 2016 at 8:00 AM, Violeta Georgieva <miles...@gmail.com>
wrote:

> Hi,
>
> 2016-07-12 23:27 GMT+03:00 Rossen Stoyanchev <rstoyanc...@pivotal.io>:
> >
> > hi-
> >
> > Starting with Tomcat 8.0.35 when an async request times out, in a
> > subsequent error dispatch request.isAsyncStarted() returns true.
> Previously
> > it returned false.
> >
> > The Servlet spec says:
> > If this request has been dispatched using one of the
> AsyncContext.dispatch
> > methods since it was put
> > in asynchronous mode, or a call to AsynContext.complete is made, this
> > method returns false.
>
> I think the following part of the specification is important:
>
> "
> In the event that an asynchronous operation times out, the container must
> run through the following steps:
> - Invoke the AsyncListener.onTimeout method on all the AsyncListener
> instances registered with the ServletRequest on which the asynchronous
> operation was initiated.
> - If none of the listeners called AsyncContext.complete() or any of the
> AsyncContext.dispatch methods, perform an error dispatch with a status code
> equal to HttpServletResponse.SC_INTERNAL_SERVER_ERROR.
> - If no matching error page was found, or the error page did not call
> AsyncContext.complete() or any of the AsyncContext.dispatch methods, the
> container MUST call AsyncContext.complete().
> "
>
> So isAsyncStarted returns true when in the error page and the error page
> should call AsyncContext.complete.
>
> What do you think?
>


My understanding of the general idea with async requests is that after
startAsync(), isAsyncStarted remains true until the thread exits. In
subsequent dispatches of any kind, isAsyncStarted is false and the
application is free to call startAsync again and exit the thread. The fact
that isAsync now returns true in an ERROR dispatch seems to go against that
general idea.

For more background, the issue was reported with a Spring Boot application
that has an SSE endpoint. In Spring Boot error dispatches are used
extensively where the same URL routing mechanisms is applied as for regular
requests. Prior to invoking the handler we have simple a sanity check to
make sure asyncStarted is false. We could remove that check but then it
means an error handler no longer can call startAsync.

For what it's worth this very long standing behavior, from the beginning of
Servet 3.0, which runs and is used without issues against many 3.0
containers. This is why I wondered if this is an intentional change of
behavior that now makes Tomcat behave differently from other containers.

isAsyncStarted=true on ERROR dispatch

[Rossen Stoyanchev]

hi-

Starting with Tomcat 8.0.35 when an async request times out, in a
subsequent error dispatch request.isAsyncStarted() returns true. Previously
it returned false.

The Servlet spec says:
If this request has been dispatched using one of the AsyncContext.dispatch
methods since it was put
in asynchronous mode, or a call to AsynContext.complete is made, this
method returns false.

No explicit mention of ERROR dispatches but I'd assume once the request
that called startAsync is done, it won't return true any more. For what
it's worth Jetty still return false on the ERROR dispatch. Here is a repro
project [1].

Before creating a ticket I wanted to check if this is expected behavior or
an unintended side effect of other changes?

Rossen

[1]
https://github.com/spring-projects/spring-framework-issues/tree/master/SPR-1

Re: [VOTE][RESULT] Release Apache Tomcat 9.0.0.M6

[Rossen Stoyanchev]

A bit late to this but I've done quick sanity checks from a Spring
Framework perspective (framework tests, websocket, Servlet 3 async, Servlet
3.1 non-blocking) with no issues encountered.

On Mon, May 16, 2016 at 6:34 AM, Mark Thomas  wrote:

> The following votes were cast:
>
> Binding:
>  - alpha: remm, markt, violetagg, fschumacher, kfujino, mgrigorov, rjung
>
>
> The vote therefore passes.
>
> Thank you to everyone who tested and/or voted on this release.
>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 8.5.2

[Rossen Stoyanchev]

On Wed, May 11, 2016 at 6:22 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.2 release is now available for voting.
>
> 8.5.2 corrects a regression found in 8.5.1.
>
> The major changes compared to the 8.5.0 release are:
> - Add the org.apache.catalina.servlet4preview package that can be
>   used to gain early access to Servlet 4.0 features. Note that this
>   package will not be present in Tomcat 9.
> - Make default TLS configuration more secure
> - Add direct HTTP/2 connection support
> - Update the packaged version of the Tomcat Native Library to 1.2.7 to
>   pick up the Windows binaries that are based on OpenSSL 1.0.2h and
>   APR 1.5.2.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.2/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1081/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_2/
>
> The proposed 8.5.2 release is:
> [ ] Broken - do not release
> [ ] Alpha  - go ahead and release as 8.5.2
> [X] Beta   - go ahead and release as 8.5.2
> [ ] Stable - go ahead and release as 8.5.2
>
>
Spring Framework tests
Portfolio Sample (WebSocket, Serlvet 3.0 async)
Spring Reactive tests (Servlet 3.1 I/O)

Re: [VOTE] Release Apache Tomcat 8.5.0

[Rossen Stoyanchev]

hi,

A public  API for initiating an upgrade at runtime was removed [1] which
breaks WebSocket support in the Spring Framework. This API was previously
added to make up for a limitation in JSR-356. The hope was for it to be
picked up in a spec update but unfortunately there has been no movement
whatsoever on that front. For what it's worth an identical API has been
added to several other Servlet containers.

Rossen

[1]
https://github.com/apache/tomcat/commit/fe72ea5deb57d7eedf00387c1d79049ca64681ee
[2] https://java.net/jira/browse/WEBSOCKET_SPEC-211

On Thu, Mar 17, 2016 at 4:00 PM, Mark Thomas  wrote:

> The proposed Apache Tomcat 8.5.0 release is now available for voting.
>
> This is the first release of the 8.5.x branch. The release is, in essence:
> - Based on a copy of the 9.0.0.M4 tag
> - All 9.0.x changes to the specification APIs have been reverted. The
>   specification APIs should match 8.0.x exactly
> - Java 8 specific code has been re-written for Java 7
> - Tomcat and specification versions have been set
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.5.0/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1066/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc8.5.x/tags/TOMCAT_8_5_0/
>
> The proposed 8.5.0 release is:
> [ ] Broken - do not release
> [ ] Alpha  - go ahead and release as 8.5.0
> [ ] Beta   - go ahead and release as 8.5.0
> [ ] Stable - go ahead and release as 8.5.0
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: [VOTE] Release Apache Tomcat 8.0.1

[Rossen Stoyanchev]

On Wed, Jan 29, 2014 at 6:43 PM, Mark Thomas ma...@apache.org wrote:


 The proposed 8.0.1 release is:
 [ ] Broken - do not release
 [ ] Alpha  - go ahead and release as 8.0.1 (alpha)
 [ ] Beta   - go ahead and release as 8.0.1 (beta)
 [x] Stable - go ahead and release as 8.0.1 (stable)


Focused on testing WebSocket and Servlet async support with Spring
Framework integration tests, sample apps, and SockJS protocol tests against
Spring's SockJS server implementation.

Rossen

Re: [VOTE] Release Apache Tomcat 8.0.0

[Rossen Stoyanchev]

I can confirm that the issue with the empty Sec-WebSocket-Protocol header
also affects Chrome 31.0.1650.63.

The actual issue appears as an Invalid UTF-8 sequence in header value
message in the Chrome dev tool. Although I had read what Martin reported
for Chrome 32, I couldn't confirm it's the same issue since I'm on Chrome
31 and the dev tools don't even show the response headers and Firefox for
some reason doesn't show the empty header. I had to use Wireshark to
confirm it's the same issue.

A (non-binding) vote not to release this way. This a pretty bad first-time
user experience for anyone who tries 8.0.

Rossen

Re: [VOTE] Release Apache Tomcat 7.0.45

[Rossen Stoyanchev]

On Wed, Sep 25, 2013 at 9:37 AM, Violeta Georgieva miles...@gmail.com wrote:
 The proposed Apache Tomcat 7.0.45 release is now available for voting.
 This release candidate contains JSR-356 Java WebSocket 1.0 implementation.
 Note that use of this functionality requires Java 7.

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.45/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-098/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_45/

 The proposed 7.0.45 release is:
 [ ] Broken - do not release
 [ ] Stable - go ahead and release as 7.0.45 Stable

+1 stable

I can confirm the exception I reported with 7.0.44 is now fixed.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.44

[Rossen Stoyanchev]

I am getting a ClassCastException when using (non JSR-356) upgrade,
i.e. WsServerContainer.doUpgrade:

Caused by: java.lang.ClassCastException:
org.springframework.security.web.servletapi.HttpServlet3RequestFactory$Servlet3SecurityContextHolderAwareRequestWrapper
cannot be cast to org.apache.catalina.connector.RequestFacade
at 
org.apache.tomcat.websocket.server.UpgradeUtil.doUpgrade(UpgradeUtil.java:183)
at 
org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(WsServerContainer.java:235)
at 
org.springframework.web.socket.server.support.TomcatRequestUpgradeStrategy.upgradeInternal(TomcatRequestUpgradeStrategy.java:77)
at 
org.springframework.web.socket.server.support.AbstractStandardUpgradeStrategy.upgrade(AbstractStandardUpgradeStrategy.java:59)
at 
org.springframework.web.socket.server.DefaultHandshakeHandler.doHandshake(DefaultHandshakeHandler.java:183)
at 
org.springframework.web.socket.sockjs.transport.handler.WebSocketTransportHandler.handleRequest(WebSocketTransportHandler.java:82)

Also what's the equivalent of the Tomcat 8 tomcat-websocket
dependency? I see the 7.0.44 binary has tomcat7-websocket.jar but I
can't find such a dependency in the staging maven repository.

Thanks,
Rossen


On Mon, Sep 23, 2013 at 4:58 PM, Violeta Georgieva miles...@gmail.com wrote:
 The proposed Apache Tomcat 7.0.44 release is now available for voting.
 This release candidate contains JSR-356 Java WebSocket 1.0 implementation.
 Note that use of this functionality requires Java 7.

 It can be obtained from:
 https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.44/
 The Maven staging repo is:
 https://repository.apache.org/content/repositories/orgapachetomcat-090/
 The svn tag is:
 http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_44/

 The proposed 7.0.44 release is:
 [ ] Broken - do not release
 [ ] Stable - go ahead and release as 7.0.44 Stable

 Regards
 Violeta

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.44

[Rossen Stoyanchev]

On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas ma...@apache.org wrote:

 Tomcat should already being the necessary unwrapping in lines 179-181.
 It isn't immediately clear to me why this isn't working as intended. Can
 you denug this and add some insight?

Indeed, the code does unwrap the request correctly but then it uses
the original req var, not inner. Doh!

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.44

[Rossen Stoyanchev]

On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas ma...@apache.org wrote:

 The necessary update to the script that uploads those JARs to the Maven
 repo was missed. I think I have fixed it locally but need to test it
 from somewhere with connectivity. Unless the JavaOne Wifi is
 significantly better than yesterday that won't be for a few hours.

I'll run tests when this is available.

Thanks,
Rossen

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Bug 55006] Add http proxy support for ClientEndpoint using system properties

[Rossen Stoyanchev]

On Mon, Jun 3, 2013 at 10:27 AM, Niki Dokovski nick...@gmail.com wrote:

 On Mon, Jun 3, 2013 at 3:44 PM, Niki Dokovski nick...@gmail.com 
 wrote:Further
 on, if you choose to use connectToServer call that has the
 ClientEndpointConfig param you are losing the annotation approach as the
 first param of this call has to be an instance of an Endpoint. Hence your
 class can not be just annotated. hmmm Mark where can we bring this
 discussion?


This is not very obvious from the API but ClientEndpointConfig (and
ServerEndpointConfig) are not meant to be used with annotated endpoints. In
other words, I think the methods accepting those types are for use with
type-based endpoints (i.e. javax.websocket.Endpoint). So as far as I can
see user properties can be updated before the session starts only for
type-based endpoints.

Rossen

TesterWsClientAutobahn failures

[Rossen Stoyanchev]

Is this expected to run successfully? I am seeing failures when running
with `wstest -m fuzzingserver`. For example in 9.1.3, when the test client
tries to send the message back, the fuzz server closes the connection with
status 1007 and reason encountered invalid UTF-8 while processing text
message at payload octet index 229230.

Furthermore, this results in exceptions on the client side that obscure the
actual server error:

SEVERE: Failed to send close message to remote endpoint
java.io.IOException: java.util.concurrent.ExecutionException:
java.io.IOException: Broken pipe
at
org.apache.tomcat.websocket.WsRemoteEndpointImplBase.startMessageBlock(WsRemoteEndpointImplBase.java:203)
at
org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:408)
at org.apache.tomcat.websocket.WsSession.close(WsSession.java:353)
at org.apache.tomcat.websocket.WsFrameClient.close(WsFrameClient.java:81)
at org.apache.tomcat.websocket.WsFrameClient.access$2(WsFrameClient.java:71)
at
org.apache.tomcat.websocket.WsFrameClient$WsFrameClientCompletionHandler.failed(WsFrameClient.java:110)
at
org.apache.tomcat.websocket.WsFrameClient$WsFrameClientCompletionHandler.failed(WsFrameClient.java:1)
at sun.nio.ch.Invoker.invokeUnchecked(Invoker.java:128)
...

Rossen