Jetty9 async response - #292
Conversation
response writes instead of jetty continuations.
instead retrieve it in `onWritePossible` as this throws an IllegalStateException for timed out requests with a more helpful error message. reduced logging output by switching some calls several to debug level
…ns and check the `isReady` state first in `onWritePossible`. modified async httpserver example to use a worker for writing the response, mimicking a more real-world situation.
|
Much cleaner and more modern than the old solution with continuations. Since Servlet 3.1 is now available over 2 years and already adopted by the JEE industry, this is a strong improvement for Ringo. |
…rbit jars configuration
|
To clarify: Ringo will then be able to serve an async non-blocking response, but the incoming request will still be parsed in a blocking way. |
|
Nice talk about Jetty 9 and Servlet 3.1: |
|
I just merged Jetty 9 into master. If this PR is ready for master, please merge @grob 👍 |
replaced jetty continuations with servlet 3.1 async responses
|
done :) |
|
When adding a major new feature (nice grob), it would be helpful for some documentation and an example. I would like to know what needs to be done for the mainstream servlet containers to support this approach. Does it play well with Stick yet? Does it require a web.xml with Servlet 3.1 XSD? |
|
If it helps others, I was able to get Async working in stick. I had to perform the following steps: Upgrade my web.xml using the new descriptor and setting the asyncSupported in my web.xml <?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<!-- Ringo Servlet -->
<servlet>
<servlet-name>ringo</servlet-name>
<servlet-class>org.ringojs.jsgi.JsgiServlet</servlet-class>
<async-supported>true</async-supported>
<init-param>
<param-name>verbose</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>optlevel</param-name>
<param-value>-1</param-value>
</init-param>
<init-param>
<param-name>production</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>bootscript</param-name>
<param-value>bootscripts/init.js</param-value>
</init-param>
<init-param>
<param-name>module-path</param-name>
<param-value>
WEB-INF/api,WEB-INF/lib,
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>ringo</servlet-name>
<url-pattern>/api/*</url-pattern>
</servlet-mapping>
</web-app>The 3.0 descriptor will also work. Here is my handler that I am using to test the async nature of the request. I don't see anything built into stick yet to make this less ugly function handle( req ) {
// I don't think the third parameter (boolean true) is supported in the AsyncResponse class
var response = new AsyncResponse(req, 2000, true)
response.start(200, {"Content-Type": "text/plain"})
spawn(function() {
for (let cnt = 0; cnt < 5; cnt += 1) {
try {
java.lang.Thread.sleep(Math.floor(Math.random() * 300))
log.info('Writing tests')
response.write('test\n')
} catch (e) {
print(e)
}
}
log.info('Closing')
response.close()
})
return response
}I'll try and add a promise example into the mix, and issue a pull request for the docs. It would be nice if @grob, @botic and others can review to see if it is correct, or if there is a much simpler mechanism. We should also update Stick to make using async handlers seamless. |
|
I updated the documentation and added a hint for the Commit 7f6a35c fixes the default |
3 participants
Replaces continuation-based asynchronous responses with servlet 3.1 implementation.