servlet-3.1

Servlet asynchronous processing support in App Engine Java 8 standard environment

半城伤御伤魂 提交于 2021-02-07 13:55:15
问题 I'm trying asynchronous processing support in servlet 3.1 with GAE J8 standard environment (no extensible environment). Basically I have a servlet annotated with @WebServlet(name = "MyServletName", urlPatterns = {"/dosomething"}, asyncSupported = true) and to obtain an instance of AsyncContext I call (in doPost method) final AsyncContext asyncContext = httpServletRequest.startAsync(httpServletRequest, httpServletResponse); But asynchronous processing support seems to have some problems in GAE

isReady() returns true in closed state - why?

前提是你 提交于 2019-12-24 21:53:16
问题 ServletOutputStream.isReady() javadoc says the following: Returns: true if a write to this ServletOutputStream will succeed, otherwise returns false. In spite of that Jetty's ServletOutputStream implementation, HttpOutput seems to behave rather confusing in the case when the stream is in CLOSED state. It returns true : case CLOSED: return true; Source: HttpOutput.java:1011. Furthermore, all three write methods in HttpOutput throws EofException when it's CLOSED : case CLOSED: throw new

Warning: JACC: For the URL pattern xxx, all but the following methods were uncovered: POST, GET

限于喜欢 提交于 2019-12-21 12:41:19
问题 In javax.faces.webapp.FacesServlet docs, it is mentioned, Allowable HTTP Methods The JSF specification only requires the use of the GET and POST http methods. If your web application does not require any other http methods, such as PUT and DELETE, please consider restricting the allowable http methods using the <http-method> and <http-method-omission> elements. Please see the Security of the Java Servlet Specification for more information the use of these elements. My application indeed does

“Closed while Pending/Unready” warnings from Jetty

谁都会走 提交于 2019-12-11 13:49:57
问题 After fixing synchronization issues in our async servlet we still got rare java.io.IOException: Closed while Pending/Unready warnings from Jetty. With the fixes above it decreased from ~90/day to ~5/day in our production system. It's rare and it seems a lot better but probably something minor is still missing. Complete stacktrace: [jetty-63523] (HttpOutput.java:287) - java.io.IOException: Closed while Pending/Unready at org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:285) at org

web.xml not found in Java EE7 project

房东的猫 提交于 2019-12-10 17:05:29
问题 I'm doing a project in eclipse with JSF 2.2 and Servlet 3.1 (Java EE7). The first problem I had was a error in the pom.xml in line: <packaging>war</packaging> Error: web.xml is missing and is set true. I researched on the internet and added the following lines in my pom.xml <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.4</version> <configuration> <failOnMissingWebXml>false</failOnMissingWebXml> </configuration> </plugin> After that the error was gone, but when running the

Understanding Jetty's “Closed while Pending/Unready” warning

可紊 提交于 2019-12-07 23:53:09
问题 We have an asynchronous servlet which produces the following warning log from Jetty: java.io.IOException: Closed while Pending/Unready After enabling debug logs I got the following stacktrace: WARN [jetty-25948] (HttpOutput.java:278) - java.io.IOException: Closed while Pending/Unready DEBUG [jetty-25948] (HttpOutput.java:279) - java.io.IOException: Closed while Pending/Unready at org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:277) ~[jetty-server.jar:9.4.8.v20171121] at org.eclipse

Understanding Jetty's “Closed while Pending/Unready” warning

筅森魡賤 提交于 2019-12-06 04:45:38
We have an asynchronous servlet which produces the following warning log from Jetty: java.io.IOException: Closed while Pending/Unready After enabling debug logs I got the following stacktrace: WARN [jetty-25948] (HttpOutput.java:278) - java.io.IOException: Closed while Pending/Unready DEBUG [jetty-25948] (HttpOutput.java:279) - java.io.IOException: Closed while Pending/Unready at org.eclipse.jetty.server.HttpOutput.close(HttpOutput.java:277) ~[jetty-server.jar:9.4.8.v20171121] at org.eclipse.jetty.server.Response.closeOutput(Response.java:1044) [jetty-server.jar:9.4.8.v20171121] at org.eclipse

Warning: JACC: For the URL pattern xxx, all but the following methods were uncovered: POST, GET

不羁岁月 提交于 2019-12-04 05:06:28
In javax.faces.webapp.FacesServlet docs, it is mentioned, Allowable HTTP Methods The JSF specification only requires the use of the GET and POST http methods. If your web application does not require any other http methods, such as PUT and DELETE, please consider restricting the allowable http methods using the <http-method> and <http-method-omission> elements. Please see the Security of the Java Servlet Specification for more information the use of these elements. My application indeed does not depend upon other HTTP methods (except GET and POST ). Therefore, I am trying to use <http-method>

Java - Async in Servlet 3.0 vs NIO in Servlet 3.1

坚强是说给别人听的谎言 提交于 2019-11-28 16:54:32
Until now, as it applies to serving http requests, I thought the terms - asynchronous and non-blocking i/o meant the same thing. But apparently, they have been implemented separately in servlet 3.0 and 3.1 respectively. I am struggling to understand the difference here... Can someone shed more light on this topic, please? Specifically, I am looking for an example of how a servlet 3.0 implementation of a server can be async, yet block on a thread? I think may be if I understand this, it may be easier to understand the exact problem that the non-blocking i/o in servlet 3.1 is trying to solve.

Java - Async in Servlet 3.0 vs NIO in Servlet 3.1

本秂侑毒 提交于 2019-11-27 00:19:33
问题 Until now, as it applies to serving http requests, I thought the terms - asynchronous and non-blocking i/o meant the same thing. But apparently, they have been implemented separately in servlet 3.0 and 3.1 respectively. I am struggling to understand the difference here... Can someone shed more light on this topic, please? Specifically, I am looking for an example of how a servlet 3.0 implementation of a server can be async, yet block on a thread? I think may be if I understand this, it may be