svn commit: r1837637 - in /tomcat/trunk: java/org/apache/coyote/http2/Stream.java webapps/docs/changelog.xml
Author: markt
Date: Wed Aug 8 09:40:37 2018
New Revision: 1837637
URL: http://svn.apache.org/viewvc?rev=1837637&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62605
Ensure ReadListener.onDataAvailable() is called when the initial request body
data arrives after the request headers when using asynchronous processing over
HTTP/2.
Modified:
tomcat/trunk/java/org/apache/coyote/http2/Stream.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/coyote/http2/Stream.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http2/Stream.java?rev=1837637&r1=1837636&r2=1837637&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http2/Stream.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http2/Stream.java Wed Aug 8 09:40:37
2018
@@ -908,10 +908,10 @@ class Stream extends AbstractStream impl
final void registerReadInterest() {
-if (inBuffer != null) {
-synchronized (inBuffer) {
-readInterest = true;
-}
+ensureBuffersExist();
+
+synchronized (inBuffer) {
+readInterest = true;
}
}
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1837637&r1=1837636&r2=1837637&view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Wed Aug 8 09:40:37 2018
@@ -138,6 +138,11 @@
62526: Correctly handle PKCS12 format key stores when the
key
store password is configured to be the empty string. (markt)
+
+62605: Ensure ReadListener.onDataAvailable() is
+called when the initial request body data arrives after the request
+headers when using asynchronous processing over HTTP/2. (markt)
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1837638 - in /tomcat/tc8.5.x/trunk: ./ java/org/apache/coyote/http2/Stream.java webapps/docs/changelog.xml
Author: markt Date: Wed Aug 8 09:41:58 2018 New Revision: 1837638 URL: http://svn.apache.org/viewvc?rev=1837638&view=rev Log: Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=62605 Ensure ReadListener.onDataAvailable() is called when the initial request body data arrives after the request headers when using asynchronous processing over HTTP/2. Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/java/org/apache/coyote/http2/Stream.java tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Wed Aug 8 09:41:58 2018 @@ -1,2 +1,2 @@ /tomcat/tc8.0.x/trunk:1809644 -/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409 ,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747 404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1 756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,1760454,1760640,1760648,1761057,1761422,1761491,1761498,1761500-1761501,1761550,1761553,1761572,1761574,1761625-1761626,1761628,1761682,1761740,1761752,1762051-176205 3,1762123,1762168,1762172,1762182,1762201-1762202,1762204,1762208,1762288,1762296,1762324,1762348,1762353,1762362,1762374,1762492,1762503,1762505,1762541,1762608,1762710,1762753,1762766,1762769,1762944,1762947,1762953,1763167,1763179,176323
[Bug 62605] Async servlet over HTTP/2 setReadListener does not work if post request data arrives much later than headers
https://bz.apache.org/bugzilla/show_bug.cgi?id=62605 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mark Thomas --- Fixed. See also bug 61719. Fixed in: - trunk for 9.0.11 onwards - 8.5.x for 8.5.33 onwards Thanks for the test case. It make tracking down the root cause very simple. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62539] WsSession cannot be GC while send close message timeout
https://bz.apache.org/bugzilla/show_bug.cgi?id=62539 --- Comment #5 from saiya <1005136...@qq.com> --- Created attachment 36077 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36077&action=edit analysis Thank you very much. What you said is right. I think it has something to do with the network. java.net.SocketTimeoutException: The current message was not fully sent within the specified timeout at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:299) ~[tomcat-embed-websocket-8.5.29.jar:8.5.29] at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendMessageBlock(WsRemoteEndpointImplBase.java:258) ~[tomcat-embed-websocket-8.5.29.jar:8.5.29] at org.apache.tomcat.websocket.WsSession.sendCloseMessage(WsSession.java:592) ~[tomcat-embed-websocket-8.5.29.jar:8.5.29] at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:480) ~[tomcat-embed-websocket-8.5.29.jar:8.5.29] at org.apache.tomcat.websocket.WsSession.close(WsSession.java:445) ~[tomcat-embed-websocket-8.5.29.jar:8.5.29] at org.apache.tomcat.websocket.WsSession.close(WsSession.java:439) ~[tomcat-embed-websocket-8.5.29.jar:8.5.29] -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62539] WsSession cannot be GC while send close message timeout
https://bz.apache.org/bugzilla/show_bug.cgi?id=62539 saiya <1005136...@qq.com> changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62539] WsSession cannot be GC while send close message timeout
https://bz.apache.org/bugzilla/show_bug.cgi?id=62539 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #6 from Mark Thomas --- No Tomcat bug has been demonstrated here. There is, however, a clear bug in the provided test case (the while loop never exits). Please do not re-open this report unless you can demonstrate a Tomcat bug. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62607] New: Catalina exits with status code 0 when the configuration is invalid
https://bz.apache.org/bugzilla/show_bug.cgi?id=62607
Bug ID: 62607
Summary: Catalina exits with status code 0 when the
configuration is invalid
Product: Tomcat 9
Version: 9.0.10
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: ebo...@apache.org
Target Milestone: -
With a malformed server.xml file, "catalina.sh confitest" reports the error and
exits with the status code 1. But with "catalina.sh run" the status code is 0
(SUCCESS). This confuses daemon management systems like systemd which might not
report the error properly, or attempt to restart the server repeatedly.
Here is a suggested fix:
--- a/java/org/apache/catalina/startup/Bootstrap.java
+++ b/java/org/apache/catalina/startup/Bootstrap.java
@@ -489,6 +489,10 @@
} else if (command.equals("start")) {
daemon.setAwait(true);
daemon.load(args);
+if (null == daemon.getServer()) {
+log.fatal("Cannot start server. Server instance is not
configured.");
+System.exit(1);
+}
daemon.start();
} else if (command.equals("stop")) {
daemon.stopServer(args);
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1837650 - in /tomcat/trunk: res/maven/tomcat-i18n-ru.pom test/webapp/WEB-INF/tags/bug62453.tag
Author: kkolinko Date: Wed Aug 8 14:05:23 2018 New Revision: 1837650 URL: http://svn.apache.org/viewvc?rev=1837650&view=rev Log: Set Subversion property svn:eol-style=native Modified: tomcat/trunk/res/maven/tomcat-i18n-ru.pom (props changed) tomcat/trunk/test/webapp/WEB-INF/tags/bug62453.tag (props changed) Propchange: tomcat/trunk/res/maven/tomcat-i18n-ru.pom -- svn:eol-style = native Propchange: tomcat/trunk/test/webapp/WEB-INF/tags/bug62453.tag -- svn:eol-style = native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1837651 - in /tomcat/tc8.5.x/trunk: res/maven/tomcat-i18n-ru.pom test/webapp/WEB-INF/tags/bug62453.tag
Author: kkolinko Date: Wed Aug 8 14:09:32 2018 New Revision: 1837651 URL: http://svn.apache.org/viewvc?rev=1837651&view=rev Log: Set Subversion property svn:eol-style=native Modified: tomcat/tc8.5.x/trunk/res/maven/tomcat-i18n-ru.pom (props changed) tomcat/tc8.5.x/trunk/test/webapp/WEB-INF/tags/bug62453.tag (props changed) Propchange: tomcat/tc8.5.x/trunk/res/maven/tomcat-i18n-ru.pom -- svn:eol-style = native Propchange: tomcat/tc8.5.x/trunk/test/webapp/WEB-INF/tags/bug62453.tag -- svn:eol-style = native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1837652 - /tomcat/tc7.0.x/trunk/res/maven/tomcat-i18n-ru.pom
Author: kkolinko Date: Wed Aug 8 14:12:32 2018 New Revision: 1837652 URL: http://svn.apache.org/viewvc?rev=1837652&view=rev Log: Set Subversion property svn:eol-style=native Modified: tomcat/tc7.0.x/trunk/res/maven/tomcat-i18n-ru.pom (props changed) Propchange: tomcat/tc7.0.x/trunk/res/maven/tomcat-i18n-ru.pom -- svn:eol-style = native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62603] Changes in tag files are not reflected in the rendered view or they end up with a java.lang.NoClassDefFoundError
https://bz.apache.org/bugzilla/show_bug.cgi?id=62603 --- Comment #1 from Mark Thomas --- Thanks for the clear description of a tricky issue. I've been looking at potential solutions. Having run through various scenarios my conclusion is that there is always a risk of problems if the reload flags are inconsistent across the web application. To avoid the potential problems, reloading needs to be prevented while the reload flags are being updated. I see two approaches to this: 1. In JspSrvletWrapper.getServlet() assume reload == false while the loop in JspRuntimeContext.checkCompile() is processing. 2. In JspSrvletWrapper.getServlet(), if reload == true && the loop in checkCompile() is processing pause the current request until checkCompile() completes. My main concern with approach 1 is that it is possible, with (un)lucky timing that, after a resource is modified requests for that resource arrive during a checkCompile() processing window meaning the updated version of the resource is not seen even if it was modified multiple checkInterval periods ago. I don't think this is intuitive and coudl lead to unexpected behaviour. With approach 2 the main concern is the length of the pause between the request being requested and processing starting. This is primarily driven by the time it takes to complete the checkCompile() loop. I am currently leaning towards approach 2 with some additional logging that will tell admins how long the chekcCompile() loop took to complete and how long individual requests were waiting. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62605] Async servlet over HTTP/2 setReadListener does not work if post request data arrives much later than headers
https://bz.apache.org/bugzilla/show_bug.cgi?id=62605 --- Comment #2 from Dapeng Zhang --- Thanks for the fix! I also noticed in some cases WriteListener callbacks are not invoked, not clear if its my fault yet, still investigating. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 62603] Changes in tag files are not reflected in the rendered view or they end up with a java.lang.NoClassDefFoundError
https://bz.apache.org/bugzilla/show_bug.cgi?id=62603 --- Comment #2 from Jordi --- Thanks for the feedback Mark. What about this variant of number 1 - In JspSrvletWrapper.getServlet() assume reload == false while the loop in JspRuntimeContext.checkCompile() is processing - Store all the JspServletWrappers affected by the previous step(in JspRuntimeContext ?) - When JspRuntimeContext.checkCompile() is completed, iterate through that "list" and reload them by invoking JspServletWrapper.getServlet I could send a PR/patch if you wish -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
