Re: isAsyncStarted=true on ERROR dispatch
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
On Wed, Jul 13, 2016 at 8:00 AM, Violeta Georgieva wrote: > Hi, > > 2016-07-12 23:27 GMT+03:00 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. > > 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
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
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
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
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
On Wed, Jan 29, 2014 at 6:43 PM, Mark Thomas 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
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
On Wed, Sep 25, 2013 at 9:37 AM, Violeta Georgieva 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
On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas 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: [VOTE] Release Apache Tomcat 7.0.44
On Tue, Sep 24, 2013 at 11:40 AM, Mark Thomas 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
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 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: Back-porting JSR-356 implementation to 7.0.x
On Thu, Aug 15, 2013 at 6:47 PM, Mark Thomas wrote: > This isn't going to be quite as simple as I first thought. > > The WebSocket client API requires Java SE 7 or later. > The WebSocket server API requires Java EE 6 or later. > Java EE 6 requires Java 6 or later. > The WebSocket server API depends on the WebSocket client API. > > The WebSocket client implementation makes extensive use of new Java 7 > non-blocking IO features. If at all feasible, could applications using the server side only use Java 6? - 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
On Mon, Jun 3, 2013 at 10:27 AM, Niki Dokovski wrote: > On Mon, Jun 3, 2013 at 3:44 PM, Niki Dokovski > 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
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