Re: svn commit: r1702962 - /tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

[jean-frederic clere]

On 09/14/2015 04:44 PM, r...@apache.org wrote:

Author: remm
Date: Mon Sep 14 14:44:06 2015
New Revision: 1702962

URL: http://svn.apache.org/r1702962
Log:
Similar to NIO2, async NIO sendfile needs to deallocate and recycle the buffer.


That fixed the java.lang.OutOfMemoryError: Direct buffer memory I had in 
my load tests.


Thanks

Jean-Frederic

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

svn commit: r1703115 - /tomcat/tc8.0.x/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java

[markt]

Author: markt
Date: Tue Sep 15 08:02:56 2015
New Revision: 1703115

URL: http://svn.apache.org/r1703115
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58378
Clarify comment on thread-safety.
Ensure the latest pathInfo value is visible to the main test thread.

Modified:

tomcat/tc8.0.x/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java

Modified: 
tomcat/tc8.0.x/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java?rev=1703115&r1=1703114&r2=1703115&view=diff
==
--- 
tomcat/tc8.0.x/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java 
(original)
+++ 
tomcat/tc8.0.x/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java 
Tue Sep 15 08:02:56 2015
@@ -255,7 +255,7 @@ public class TestCoyoteAdapter extends T
 
 private static final long serialVersionUID = 1L;
 
-private String pathInfo = null;
+private volatile String pathInfo = null;
 
 public String getPathInfo() {
 return pathInfo;
@@ -265,7 +265,8 @@ public class TestCoyoteAdapter extends T
 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-// Not thread safe
+// Not thread safe. Concurrent requests to this servlet will
+// over-write all the results but the last processed.
 pathInfo = req.getPathInfo();
 }
 }



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

svn commit: r1703116 - /tomcat/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java

[markt]

Author: markt
Date: Tue Sep 15 08:04:43 2015
New Revision: 1703116

URL: http://svn.apache.org/r1703116
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58378
Clarify comment on thread-safety.
Ensure the latest pathInfo value is visible to the main test thread.

Modified:
tomcat/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java

Modified: tomcat/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java?rev=1703116&r1=1703115&r2=1703116&view=diff
==
--- tomcat/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java 
(original)
+++ tomcat/trunk/test/org/apache/catalina/connector/TestCoyoteAdapter.java Tue 
Sep 15 08:04:43 2015
@@ -255,7 +255,7 @@ public class TestCoyoteAdapter extends T
 
 private static final long serialVersionUID = 1L;
 
-private String pathInfo = null;
+private volatile String pathInfo = null;
 
 public String getPathInfo() {
 return pathInfo;
@@ -265,7 +265,8 @@ public class TestCoyoteAdapter extends T
 protected void doGet(HttpServletRequest req, HttpServletResponse resp)
 throws ServletException, IOException {
 
-// Not thread safe
+// Not thread safe. Concurrent requests to this servlet will
+// over-write all the results but the last processed.
 pathInfo = req.getPathInfo();
 }
 }



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

[Bug 58378] Data race on field org.apache.catalina.connector.TestCoyoteAdapter$PathInfoServlet.pathInfo

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58378

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mark Thomas  ---
Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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

buildbot exception in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a build exception on builder tomcat-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/275

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1703116
Blamelist: markt

BUILD FAILED: exception upload_2

Sincerely,
 -The Buildbot




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

[GUMP@vmgump]: Project tomcat-tc8.0.x-validate (in module tomcat-8.0.x) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at gene...@gump.apache.org.

Project tomcat-tc8.0.x-validate has an issue affecting its community 
integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-tc8.0.x-validate :  Tomcat 8.x, a web server implementing the Java 
Servlet 3.1,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Dependency on checkstyle exists, no need to add for property 
checkstyle.jar.
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/gump_work/build_tomcat-8.0.x_tomcat-tc8.0.x-validate.html
Work Name: build_tomcat-8.0.x_tomcat-tc8.0.x-validate (Type: Build)
Work ended in a state of : Failed
Elapsed: 1 min 3 secs
Command Line: /usr/lib/jvm/java-8-oracle/bin/java -Djava.awt.headless=true 
-Dbuild.sysclasspath=only org.apache.tools.ant.Main 
-Dgump.merge=/srv/gump/public/gump/work/merge.xml 
-Dcheckstyle.jar=/srv/gump/public/workspace/checkstyle/target/checkstyle-6.11-SNAPSHOT.jar
 -Dexecute.validate=true validate 
[Working Directory: /srv/gump/public/workspace/tomcat-8.0.x]
CLASSPATH: 
/usr/lib/jvm/java-8-oracle/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit4.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/xml-commons/java/build/resolver.jar:/srv/gump/public/workspace/checkstyle/target/checkstyle-6.11-SNAPSHOT.jar:/srv/gump/packages/antlr/antlr-3.1.3.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-20150915.jar:/srv/gump/packages/commons-collections3/commons-collections-3.2.1.jar:/srv/gump/public/workspace/apache-commons/cli/target/commons-cli-1.4-SNAPSHOT.jar:/srv/gump/public/workspace/commons-lang-trunk/target/commons-lang3-3.5-SNAPSHOT.ja
 
r:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-20150915.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-20150915.jar:/srv/gump/packages/guava/guava-18.0.jar
-
Buildfile: /srv/gump/public/workspace/tomcat-8.0.x/build.xml

build-prepare:
   [delete] Deleting directory 
/srv/gump/public/workspace/tomcat-8.0.x/output/build/temp
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-8.0.x/output/build/temp

compile-prepare:

download-validate:

testexist:
 [echo] Testing  for 
/srv/gump/public/workspace/checkstyle/target/checkstyle-6.11-SNAPSHOT.jar

setproxy:

downloadfile:

validate:
[mkdir] Created dir: 
/srv/gump/public/workspace/tomcat-8.0.x/output/res/checkstyle
[checkstyle] Running Checkstyle 6.11-SNAPSHOT on 2959 files
[checkstyle] 
/srv/gump/public/workspace/tomcat-8.0.x/test/org/apache/tomcat/util/http/TesterHttpMessagesPerformance.java:1:
 error: Line does not match expected header line of '^(rem)?\W*Licensed to the 
Apache Software Foundation \(ASF\) under one or more$'.

BUILD FAILED
/srv/gump/public/workspace/tomcat-8.0.x/build.xml:540: Got 1 errors and 0 
warnings.

Total time: 1 minute 3 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/tomcat-8.0.x/tomcat-tc8.0.x-validate/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 20150915060003, vmgump.apache.org:vmgump:20150915060003
Gump E-mail Identifier (unique within run) #1.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

svn commit: r1703140 - /tomcat/tc8.0.x/trunk/test/org/apache/tomcat/util/http/TesterHttpMessagesPerformance.java

[markt]

Author: markt
Date: Tue Sep 15 10:26:58 2015
New Revision: 1703140

URL: http://svn.apache.org/r1703140
Log:
Add missing license header

Modified:

tomcat/tc8.0.x/trunk/test/org/apache/tomcat/util/http/TesterHttpMessagesPerformance.java

Modified: 
tomcat/tc8.0.x/trunk/test/org/apache/tomcat/util/http/TesterHttpMessagesPerformance.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/test/org/apache/tomcat/util/http/TesterHttpMessagesPerformance.java?rev=1703140&r1=1703139&r2=1703140&view=diff
==
--- 
tomcat/tc8.0.x/trunk/test/org/apache/tomcat/util/http/TesterHttpMessagesPerformance.java
 (original)
+++ 
tomcat/tc8.0.x/trunk/test/org/apache/tomcat/util/http/TesterHttpMessagesPerformance.java
 Tue Sep 15 10:26:58 2015
@@ -1,3 +1,19 @@
+/*
+ *  Licensed to the Apache Software Foundation (ASF) under one or more
+ *  contributor license agreements.  See the NOTICE file distributed with
+ *  this work for additional information regarding copyright ownership.
+ *  The ASF licenses this file to You under the Apache License, Version 2.0
+ *  (the "License"); you may not use this file except in compliance with
+ *  the License.  You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ *  Unless required by applicable law or agreed to in writing, software
+ *  distributed under the License is distributed on an "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *  See the License for the specific language governing permissions and
+ *  limitations under the License.
+ */
 package org.apache.tomcat.util.http;
 
 import java.util.Locale;



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

svn commit: r1703143 - /tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java

[markt]

Author: markt
Date: Tue Sep 15 10:38:05 2015
New Revision: 1703143

URL: http://svn.apache.org/r1703143
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58379
Updates to the socketWrapper need to be visible to async threads.

Modified:
tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java

Modified: tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java?rev=1703143&r1=1703142&r2=1703143&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/AbstractProcessor.java Tue Sep 15 
10:38:05 2015
@@ -41,7 +41,7 @@ public abstract class AbstractProcessor
 protected final AbstractEndpoint endpoint;
 protected final Request request;
 protected final Response response;
-protected SocketWrapperBase socketWrapper = null;
+protected volatile SocketWrapperBase socketWrapper = null;
 private String clientCertProvider = null;
 
 /**



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

svn commit: r1703144 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/coyote/AbstractProcessor.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep 15 10:40:44 2015
New Revision: 1703144

URL: http://svn.apache.org/r1703144
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58379
Updates to the socketWrapper need to be visible to async threads.

Modified:
tomcat/tc8.0.x/trunk/   (props changed)
tomcat/tc8.0.x/trunk/java/org/apache/coyote/AbstractProcessor.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 10:40:44 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501,1694548,1694658,1694660,1694788,1694872,1694878,1695006,1695

[Bug 58379] Data race on field org.apache.coyote.AbstractProcessor.socketWrapper

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58379

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mark Thomas  ---
Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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

buildbot failure in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/276

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1703143
Blamelist: markt

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

svn commit: r1703146 - /tomcat/trunk/java/org/apache/catalina/session/StandardSession.java

[markt]

Author: markt
Date: Tue Sep 15 10:52:42 2015
New Revision: 1703146

URL: http://svn.apache.org/r1703146
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58380
Both maxInactiveInterval and isNew can be accessed concurrently so they need to 
be volatile

Modified:
tomcat/trunk/java/org/apache/catalina/session/StandardSession.java

Modified: tomcat/trunk/java/org/apache/catalina/session/StandardSession.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/StandardSession.java?rev=1703146&r1=1703145&r2=1703146&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/session/StandardSession.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/session/StandardSession.java Tue Sep 
15 10:52:42 2015
@@ -222,13 +222,13 @@ public class StandardSession implements
  * the servlet container may invalidate this session.  A negative time
  * indicates that the session should never time out.
  */
-protected int maxInactiveInterval = -1;
+protected volatile int maxInactiveInterval = -1;
 
 
 /**
  * Flag indicating whether this session is new or not.
  */
-protected boolean isNew = false;
+protected volatile boolean isNew = false;
 
 
 /**



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

svn commit: r1703147 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/session/StandardSession.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep 15 10:56:36 2015
New Revision: 1703147

URL: http://svn.apache.org/r1703147
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58380
Both maxInactiveInterval and isNew can be accessed concurrently so they need to 
be volatile

Modified:
tomcat/tc8.0.x/trunk/   (props changed)
tomcat/tc8.0.x/trunk/java/org/apache/catalina/session/StandardSession.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 10:56:36 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501,1694548,1694658,1694660,1

[Bug 58380] Data races inside org.apache.catalina.session.StandardSession

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58380

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Mark Thomas  ---
Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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

buildbot exception in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a build exception on builder tomcat-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/277

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1703146
Blamelist: markt

BUILD FAILED: exception upload_2

Sincerely,
 -The Buildbot




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

svn commit: r1703151 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

[markt]

Author: markt
Date: Tue Sep 15 11:11:51 2015
New Revision: 1703151

URL: http://svn.apache.org/r1703151
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58381
The list of events is accessed by multiple threads so use a thread safe Deque 
implementation.
Fix a Javadoc comment
Simplify the code a little

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java?rev=1703151&r1=1703150&r2=1703151&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
Tue Sep 15 11:11:51 2015
@@ -27,9 +27,10 @@ import java.nio.channels.SelectionKey;
 import java.nio.channels.Selector;
 import java.nio.channels.ServerSocketChannel;
 import java.nio.channels.SocketChannel;
+import java.util.Deque;
 import java.util.Iterator;
-import java.util.LinkedList;
 import java.util.Set;
+import java.util.concurrent.ConcurrentLinkedDeque;
 import java.util.concurrent.atomic.AtomicReference;
 
 import org.apache.catalina.tribes.io.ObjectReader;
@@ -56,7 +57,7 @@ public class NioReceiver extends Receive
 private ServerSocketChannel serverChannel = null;
 private DatagramChannel datagramChannel = null;
 
-protected final LinkedList events = new LinkedList<>();
+protected final Deque events = new ConcurrentLinkedDeque<>();
 
 public NioReceiver() {
 }
@@ -68,8 +69,10 @@ public class NioReceiver extends Receive
 }
 
 /**
- * start cluster receiver
- * @throws IOException
+ * Start cluster receiver.
+ *
+ * @throws IOException If the receiver fails to start
+ *
  * @see org.apache.catalina.tribes.ChannelReceiver#start()
  */
 @Override
@@ -141,25 +144,33 @@ public class NioReceiver extends Receive
 
 public void addEvent(Runnable event) {
 Selector selector = this.selector.get();
-if ( selector != null ) {
+if (selector != null) {
 synchronized (events) {
 events.add(event);
 }
-if ( log.isTraceEnabled() ) log.trace("Adding event to 
selector:"+event);
-if ( isListening() ) selector.wakeup();
+if (log.isTraceEnabled()) {
+log.trace("Adding event to selector:" + event);
+}
+if (isListening()) {
+selector.wakeup();
+}
 }
 }
 
 public void events() {
-if ( events.size() == 0 ) return;
+if (events.size() == 0) {
+return;
+}
 synchronized (events) {
 Runnable r = null;
-while ( (events.size() > 0) && (r = events.removeFirst()) != null 
) {
+while ((r = events.pollFirst()) != null ) {
 try {
-if ( log.isTraceEnabled() ) log.trace("Processing event in 
selector:"+r);
+if (log.isTraceEnabled()) {
+log.trace("Processing event in selector:" + r);
+}
 r.run();
-} catch ( Exception x ) {
-log.error("",x);
+} catch (Exception x) {
+log.error("", x);
 }
 }
 events.clear();



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

svn commit: r1703153 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/transport/nio/NioReceiver.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep 15 11:14:35 2015
New Revision: 1703153

URL: http://svn.apache.org/r1703153
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58381
The list of events is accessed by multiple threads so use a thread safe Deque 
implementation.
Fix a Javadoc comment
Simplify the code a little

Modified:
tomcat/tc8.0.x/trunk/   (props changed)

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 11:14:35 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693

[Bug 58381] Data race inside non-thread-safe LinkedList org.apache.catalina.tribes.transport.nio.NioReceiver.events

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58381

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mark Thomas  ---
Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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

buildbot failure in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/278

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1703151
Blamelist: markt

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

svn commit: r1703160 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 11:55:10 2015
New Revision: 1703160

URL: http://svn.apache.org/r1703160
Log:
Deprecate unused code

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1703160&r1=1703159&r2=1703160&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java Tue 
Sep 15 11:55:10 2015
@@ -255,10 +255,12 @@ public class Membership implements Clone
 }
 
 /**
- * get a copy from all member entries
+ * Get a copy from all member entries.
+ *
+ * @deprecated Unused. Will be removed in Tomcat 9.0.x.
  */
-protected synchronized MbrEntry[] getMemberEntries()
-{
+@Deprecated
+protected synchronized MbrEntry[] getMemberEntries() {
 MbrEntry[] result = new MbrEntry[map.size()];
 Iterator> i = map.entrySet().iterator();
 int pos = 0;



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

svn commit: r1703161 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 11:55:49 2015
New Revision: 1703161

URL: http://svn.apache.org/r1703161
Log:
Deprecate unused code

Modified:
tomcat/tc8.0.x/trunk/   (props changed)

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 11:55:49 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501,1694548,1694658,1694660,1694788,1694872,1694878,1695006,1695354,1695371,1695459,1695582,1695706,1695778,1696199,1696272,1696280,1696366-1696368,1696378,1696390,1696392,1696467,1700607,1700870,1700896

svn commit: r1703162 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 11:56:18 2015
New Revision: 1703162

URL: http://svn.apache.org/r1703162
Log:
Remove deprecated, unused code

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1703162&r1=1703161&r2=1703162&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java Tue 
Sep 15 11:56:18 2015
@@ -24,8 +24,6 @@ import java.util.Arrays;
 import java.util.Comparator;
 import java.util.HashMap;
 import java.util.Iterator;
-import java.util.Map;
-
 import org.apache.catalina.tribes.Member;
 
 /**
@@ -254,20 +252,6 @@ public class Membership implements Clone
 }
 }
 
-/**
- * Get a copy from all member entries.
- *
- * @deprecated Unused. Will be removed in Tomcat 9.0.x.
- */
-@Deprecated
-protected synchronized MbrEntry[] getMemberEntries() {
-MbrEntry[] result = new MbrEntry[map.size()];
-Iterator> i = map.entrySet().iterator();
-int pos = 0;
-while ( i.hasNext() )
-result[pos++] = i.next().getValue();
-return result;
-}
 
 // - Inner Class
 



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

buildbot exception in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a build exception on builder tomcat-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/279

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1703162
Blamelist: markt

BUILD FAILED: exception upload_2

Sincerely,
 -The Buildbot




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

svn commit: r1703164 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 12:03:50 2015
New Revision: 1703164

URL: http://svn.apache.org/r1703164
Log:
Fix Javadoc

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1703164&r1=1703163&r2=1703164&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java Tue 
Sep 15 12:03:50 2015
@@ -139,7 +139,10 @@ public class Membership implements Clone
 
 /**
  * Add a member to this component and sort array with memberComparator
+ *
  * @param member The member to add
+ *
+ * @return The member entry created for this new member.
  */
 public synchronized MbrEntry addMember(Member member) {
   synchronized (membersLock) {
@@ -217,7 +220,10 @@ public class Membership implements Clone
 }
 
 /**
- * Returning that service has members or not
+ * Returning that service has members or not.
+ *
+ * @return true if there are one or more members, otherwise
+ * false
  */
 public boolean hasMembers() {
 return members.length > 0 ;
@@ -241,8 +247,10 @@ public class Membership implements Clone
 }
 
 /**
- * Returning a list of all the members in the membership
+ * Returning a list of all the members in the membership.
  * We not need a copy: add and remove generate new arrays.
+ *
+ * @return An array of the current members
  */
 public Member[] getMembers() {
 if(hasMembers()) {
@@ -293,15 +301,21 @@ public class Membership implements Clone
 }
 
 /**
- * Return the actual Member object
+ * Obtain the member associated with this entry.
+ *
+ * @return The member for this entry.
  */
 public Member getMember() {
 return mbr;
 }
 
 /**
- * Check if this dude has expired
+ * Check if this member has expired.
+ *
  * @param maxtime The time threshold
+ *
+ * @return true if the member has expired, otherwise
+ * false
  */
 public boolean hasExpired(long maxtime) {
 long delta = System.currentTimeMillis() - lastHeardFrom;



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

svn commit: r1703167 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 12:16:41 2015
New Revision: 1703167

URL: http://svn.apache.org/r1703167
Log:
Code clean-up.
Should be no functional change.

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1703167&r1=1703166&r2=1703167&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java Tue 
Sep 15 12:16:41 2015
@@ -14,10 +14,8 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
 package org.apache.catalina.tribes.membership;
 
-
 import java.io.Serializable;
 import java.util.ArrayList;
 import java.util.Arrays;
@@ -41,8 +39,7 @@ public class Membership implements Clone
 private final Object membersLock = new Object();
 
 /**
- * The name of this membership, has to be the same as the name for the 
local
- * member
+ * The local member.
  */
 protected final Member local;
 
@@ -57,8 +54,8 @@ public class Membership implements Clone
 protected Member[] members = EMPTY_MEMBERS;
 
 /**
-  * sort members by alive time
-  */
+ * Comparator for sorting members by alive time.
+ */
 protected final Comparator memberComparator;
 
 @Override
@@ -93,12 +90,15 @@ public class Membership implements Clone
 
 public Membership(Member local, Comparator comp, boolean 
includeLocal) {
 this.local = local;
-if ( includeLocal ) addMember(local);
+if (includeLocal) {
+addMember(local);
+}
 this.memberComparator = comp;
 }
+
 /**
- * Reset the membership and start over fresh.
- * Ie, delete all the members and wait for them to ping again and join 
this membership
+ * Reset the membership and start over fresh. i.e., delete all the members
+ * and wait for them to ping again and join this membership.
  */
 public synchronized void reset() {
 map.clear();
@@ -113,18 +113,19 @@ public class Membership implements Clone
  * - false if this member is the local member or updated.
  */
 public synchronized boolean memberAlive(Member member) {
-boolean result = false;
 //ignore ourselves
-if (  member.equals(local) ) return result;
+if ( member.equals(local)) {
+return false;
+}
 
-//return true if the membership has changed
+boolean result = false;
 MbrEntry entry = map.get(member);
-if ( entry == null ) {
+if (entry == null) {
 entry = addMember(member);
 result = true;
} else {
 //update the member alive time
-Member updateMember = entry.getMember() ;
+Member updateMember = entry.getMember();
 if(updateMember.getMemberAliveTime() != 
member.getMemberAliveTime()) {
 //update fields that can change
 updateMember.setMemberAliveTime(member.getMemberAliveTime());
@@ -145,18 +146,20 @@ public class Membership implements Clone
  * @return The member entry created for this new member.
  */
 public synchronized MbrEntry addMember(Member member) {
-  synchronized (membersLock) {
-  MbrEntry entry = new MbrEntry(member);
-  if (!map.containsKey(member) ) {
-  map.put(member, entry);
-  Member results[] = new Member[members.length + 1];
-  for (int i = 0; i < members.length; i++) results[i] = members[i];
-  results[members.length] = member;
-  members = results;
-  Arrays.sort(members, memberComparator);
-  }
-  return entry;
-  }
+synchronized (membersLock) {
+MbrEntry entry = new MbrEntry(member);
+if (!map.containsKey(member) ) {
+map.put(member, entry);
+Member results[] = new Member[members.length + 1];
+for (int i = 0; i < members.length; i++) {
+results[i] = members[i];
+}
+results[members.length] = member;
+members = results;
+Arrays.sort(members, memberComparator);
+}
+return entry;
+}
 }
 
 /**
@@ -178,8 +181,9 @@ public class Membership implements Clone
 Member results[] = new Member[members.length - 1];
 int j = 0;
 for (int i = 0; i < members.length; i++) {
-if (i != n)
+if (i != n) {
 results[j++] = members[i];
+}
 }
 members = resu

svn commit: r1703174 - /tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 12:41:35 2015
New Revision: 1703174

URL: http://svn.apache.org/r1703174
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58382
Use single object (membersLock) for all locking
Make members volatile so single reads are safe
Reduce scope of locks where possible
Expand scope of locks where necessary

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1703174&r1=1703173&r2=1703174&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.java Tue 
Sep 15 12:41:35 2015
@@ -46,12 +46,12 @@ public class Membership implements Clone
 /**
  * A map of all the members in the cluster.
  */
-protected HashMap map = new HashMap<>();
+protected HashMap map = new HashMap<>(); // Guarded by 
membersLock
 
 /**
  * A list of all the members in the cluster.
  */
-protected Member[] members = EMPTY_MEMBERS;
+protected volatile Member[] members = EMPTY_MEMBERS; // Guarded by 
membersLock
 
 /**
  * Comparator for sorting members by alive time.
@@ -90,19 +90,21 @@ public class Membership implements Clone
 
 public Membership(Member local, Comparator comp, boolean 
includeLocal) {
 this.local = local;
+this.memberComparator = comp;
 if (includeLocal) {
 addMember(local);
 }
-this.memberComparator = comp;
 }
 
 /**
  * Reset the membership and start over fresh. i.e., delete all the members
  * and wait for them to ping again and join this membership.
  */
-public synchronized void reset() {
-map.clear();
-members = EMPTY_MEMBERS ;
+public void reset() {
+synchronized (membersLock) {
+map.clear();
+members = EMPTY_MEMBERS ;
+}
 }
 
 /**
@@ -112,29 +114,31 @@ public class Membership implements Clone
  * @return - true if this member is new to the cluster, false 
otherwise.
  * - false if this member is the local member or updated.
  */
-public synchronized boolean memberAlive(Member member) {
-//ignore ourselves
-if ( member.equals(local)) {
+public boolean memberAlive(Member member) {
+// Ignore ourselves
+if (member.equals(local)) {
 return false;
 }
 
 boolean result = false;
-MbrEntry entry = map.get(member);
-if (entry == null) {
-entry = addMember(member);
-result = true;
-   } else {
-//update the member alive time
-Member updateMember = entry.getMember();
-if(updateMember.getMemberAliveTime() != 
member.getMemberAliveTime()) {
-//update fields that can change
-updateMember.setMemberAliveTime(member.getMemberAliveTime());
-updateMember.setPayload(member.getPayload());
-updateMember.setCommand(member.getCommand());
-Arrays.sort(members, memberComparator);
+synchronized (membersLock) {
+MbrEntry entry = map.get(member);
+if (entry == null) {
+entry = addMember(member);
+result = true;
+} else {
+// Update the member alive time
+Member updateMember = entry.getMember();
+if (updateMember.getMemberAliveTime() != 
member.getMemberAliveTime()) {
+// Update fields that can change
+
updateMember.setMemberAliveTime(member.getMemberAliveTime());
+updateMember.setPayload(member.getPayload());
+updateMember.setCommand(member.getCommand());
+Arrays.sort(members, memberComparator);
+}
 }
+entry.accessed();
 }
-entry.accessed();
 return result;
 }
 
@@ -145,9 +149,9 @@ public class Membership implements Clone
  *
  * @return The member entry created for this new member.
  */
-public synchronized MbrEntry addMember(Member member) {
+public MbrEntry addMember(Member member) {
+MbrEntry entry = new MbrEntry(member);
 synchronized (membersLock) {
-MbrEntry entry = new MbrEntry(member);
 if (!map.containsKey(member) ) {
 map.put(member, entry);
 Member results[] = new Member[members.length + 1];
@@ -158,8 +162,8 @@ public class Membership implements Clone
 members = results;
 Arrays.sort(members, memberComparator);
 }
-return entry;

svn commit: r1703175 - /tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 12:44:55 2015
New Revision: 1703175

URL: http://svn.apache.org/r1703175
Log:
Fix Javadoc

Modified:

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Modified: 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1703175&r1=1703174&r2=1703175&view=diff
==
--- 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
(original)
+++ 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
Tue Sep 15 12:44:55 2015
@@ -141,7 +141,10 @@ public class Membership implements Clone
 
 /**
  * Add a member to this component and sort array with memberComparator
+ *
  * @param member The member to add
+ *
+ * @return The member entry created for this new member.
  */
 public synchronized MbrEntry addMember(Member member) {
   synchronized (membersLock) {
@@ -219,7 +222,10 @@ public class Membership implements Clone
 }
 
 /**
- * Returning that service has members or not
+ * Returning that service has members or not.
+ *
+ * @return true if there are one or more members, otherwise
+ * false
  */
 public boolean hasMembers() {
 return members.length > 0 ;
@@ -243,8 +249,10 @@ public class Membership implements Clone
 }
 
 /**
- * Returning a list of all the members in the membership
+ * Returning a list of all the members in the membership.
  * We not need a copy: add and remove generate new arrays.
+ *
+ * @return An array of the current members
  */
 public Member[] getMembers() {
 if(hasMembers()) {
@@ -309,15 +317,21 @@ public class Membership implements Clone
 }
 
 /**
- * Return the actual Member object
+ * Obtain the member associated with this entry.
+ *
+ * @return The member for this entry.
  */
 public Member getMember() {
 return mbr;
 }
 
 /**
- * Check if this dude has expired
+ * Check if this member has expired.
+ *
  * @param maxtime The time threshold
+ *
+ * @return true if the member has expired, otherwise
+ * false
  */
 public boolean hasExpired(long maxtime) {
 long delta = System.currentTimeMillis() - lastHeardFrom;



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

svn commit: r1703176 - /tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java

[markt]

Author: markt
Date: Tue Sep 15 12:45:24 2015
New Revision: 1703176

URL: http://svn.apache.org/r1703176
Log:
Code clean-up.
Should be no functional change.

Modified:

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java

Modified: 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java?rev=1703176&r1=1703175&r2=1703176&view=diff
==
--- 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
(original)
+++ 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java 
Tue Sep 15 12:45:24 2015
@@ -14,10 +14,8 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
 package org.apache.catalina.tribes.membership;
 
-
 import java.io.Serializable;
 import java.util.ArrayList;
 import java.util.Arrays;
@@ -43,8 +41,7 @@ public class Membership implements Clone
 private final Object membersLock = new Object();
 
 /**
- * The name of this membership, has to be the same as the name for the 
local
- * member
+ * The local member.
  */
 protected final Member local;
 
@@ -59,8 +56,8 @@ public class Membership implements Clone
 protected Member[] members = EMPTY_MEMBERS;
 
 /**
-  * sort members by alive time
-  */
+ * Comparator for sorting members by alive time.
+ */
 protected final Comparator memberComparator;
 
 @Override
@@ -95,12 +92,15 @@ public class Membership implements Clone
 
 public Membership(Member local, Comparator comp, boolean 
includeLocal) {
 this.local = local;
-if ( includeLocal ) addMember(local);
+if (includeLocal) {
+addMember(local);
+}
 this.memberComparator = comp;
 }
+
 /**
- * Reset the membership and start over fresh.
- * Ie, delete all the members and wait for them to ping again and join 
this membership
+ * Reset the membership and start over fresh. i.e., delete all the members
+ * and wait for them to ping again and join this membership.
  */
 public synchronized void reset() {
 map.clear();
@@ -115,18 +115,19 @@ public class Membership implements Clone
  * - false if this member is the local member or updated.
  */
 public synchronized boolean memberAlive(Member member) {
-boolean result = false;
 //ignore ourselves
-if (  member.equals(local) ) return result;
+if ( member.equals(local)) {
+return false;
+}
 
-//return true if the membership has changed
+boolean result = false;
 MbrEntry entry = map.get(member);
-if ( entry == null ) {
+if (entry == null) {
 entry = addMember(member);
 result = true;
} else {
 //update the member alive time
-Member updateMember = entry.getMember() ;
+Member updateMember = entry.getMember();
 if(updateMember.getMemberAliveTime() != 
member.getMemberAliveTime()) {
 //update fields that can change
 updateMember.setMemberAliveTime(member.getMemberAliveTime());
@@ -147,18 +148,20 @@ public class Membership implements Clone
  * @return The member entry created for this new member.
  */
 public synchronized MbrEntry addMember(Member member) {
-  synchronized (membersLock) {
-  MbrEntry entry = new MbrEntry(member);
-  if (!map.containsKey(member) ) {
-  map.put(member, entry);
-  Member results[] = new Member[members.length + 1];
-  for (int i = 0; i < members.length; i++) results[i] = members[i];
-  results[members.length] = member;
-  members = results;
-  Arrays.sort(members, memberComparator);
-  }
-  return entry;
-  }
+synchronized (membersLock) {
+MbrEntry entry = new MbrEntry(member);
+if (!map.containsKey(member) ) {
+map.put(member, entry);
+Member results[] = new Member[members.length + 1];
+for (int i = 0; i < members.length; i++) {
+results[i] = members[i];
+}
+results[members.length] = member;
+members = results;
+Arrays.sort(members, memberComparator);
+}
+return entry;
+}
 }
 
 /**
@@ -180,8 +183,9 @@ public class Membership implements Clone
 Member results[] = new Member[members.length - 1];
 int j = 0;
 for (int i = 0; i < members.length; i++) {
-if (i != n)
+if (i != n) {
 results[j++] = members[i];
+}

svn commit: r1703177 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/membership/Membership.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep 15 12:45:48 2015
New Revision: 1703177

URL: http://svn.apache.org/r1703177
Log:
Use single object (membersLock) for all locking
Make members volatile so single reads are safe
Reduce scope of locks where possible
Expand scope of locks where necessary

Modified:
tomcat/tc8.0.x/trunk/   (props changed)

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 12:45:48 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501

[Bug 58382] Data races inside org.apache.catalina.tribes.membership.Membership

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58382

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Mark Thomas  ---
Lots to fix in that class.

Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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 58284] StandardSession attempts to silently write NonSerializable objects

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58284

--- Comment #8 from Mark Thomas  ---
Ping? I'm likely to be in a position to start the next 8.0.x release soon and
this needs to be fixed before the tag. If no patch is forthcoming, I'll likely
end up writing the patch myself.

-- 
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

buildbot failure in ASF Buildbot on tomcat-trunk

[buildbot]

The Buildbot has detected a new failure on builder tomcat-trunk while building 
ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-trunk/builds/282

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-commit' 
triggered this build
Build Source Stamp: [branch tomcat/trunk] 1703174
Blamelist: markt

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot




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

svn commit: r1703192 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/SenderState.java

[markt]

Author: markt
Date: Tue Sep 15 13:26:32 2015
New Revision: 1703192

URL: http://svn.apache.org/r1703192
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58383
Fix data race on getSenderState

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/SenderState.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/SenderState.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/SenderState.java?rev=1703192&r1=1703191&r2=1703192&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/transport/SenderState.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/transport/SenderState.java Tue 
Sep 15 13:26:32 2015
@@ -14,51 +14,39 @@
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
-
 package org.apache.catalina.tribes.transport;
 
-import java.util.HashMap;
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
 
 import org.apache.catalina.tribes.Member;
 
-
-/**
- *
- * @version 1.0
- * @since 5.5.16
- */
-
 public class SenderState {
 
 public static final int READY = 0;
 public static final int SUSPECT = 1;
 public static final int FAILING = 2;
 
-protected static final HashMap memberStates =
-new HashMap<>();
+protected static final Map memberStates = new 
ConcurrentHashMap<>();
 
 public static SenderState getSenderState(Member member) {
-return getSenderState(member,true);
+return getSenderState(member, true);
 }
 
 public static SenderState getSenderState(Member member, boolean create) {
 SenderState state = memberStates.get(member);
-if ( state == null && create) {
-synchronized ( memberStates ) {
-state = memberStates.get(member);
-if ( state == null ) {
-state = new SenderState();
-memberStates.put(member,state);
-}
+if (state == null && create) {
+state = new SenderState();
+SenderState current = memberStates.putIfAbsent(member, state);
+if (current != null) {
+state = current;
 }
 }
 return state;
 }
 
 public static void removeSenderState(Member member) {
-synchronized ( memberStates ) {
-memberStates.remove(member);
-}
+memberStates.remove(member);
 }
 
 



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

svn commit: r1703193 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/transport/SenderState.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep 15 13:28:22 2015
New Revision: 1703193

URL: http://svn.apache.org/r1703193
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58383
Fix data race on getSenderState

Modified:
tomcat/tc8.0.x/trunk/   (props changed)

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/SenderState.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 13:28:22 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501,1694548,1694658,1694660,1694788,1694872,1694878,1695006,1695354,1695371,1695459,

[Bug 58383] Data race inside non-thread-safe HashMap org.apache.catalina.tribes.transport.SenderState.memberStates

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58383

Mark Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Mark Thomas  ---
Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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

buildbot exception in ASF Buildbot on tomcat-8-trunk

[buildbot]

The Buildbot has detected a build exception on builder tomcat-8-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-8-trunk/builds/123

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-8-commit' 
triggered this build
Build Source Stamp: [branch tomcat/tc8.0.x/trunk] 1703193
Blamelist: markt

BUILD FAILED: exception upload_2

Sincerely,
 -The Buildbot




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

svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[markt]

Author: markt
Date: Tue Sep 15 13:43:55 2015
New Revision: 1703194

URL: http://svn.apache.org/r1703194
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
Calls to backgroundProcess() may come from different threads

Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

Modified: 
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java?rev=1703194&r1=1703193&r2=1703194&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java 
(original)
+++ tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java Tue 
Sep 15 13:43:55 2015
@@ -92,7 +92,7 @@ public class WsWebSocketContainer implem
 private int maxBinaryMessageBufferSize = Constants.DEFAULT_BUFFER_SIZE;
 private int maxTextMessageBufferSize = Constants.DEFAULT_BUFFER_SIZE;
 private volatile long defaultMaxSessionIdleTimeout = 0;
-private int backgroundProcessCount = 0;
+private volatile int backgroundProcessCount = 0;
 private int processPeriod = Constants.DEFAULT_PROCESS_PERIOD;
 
 



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

svn commit: r1703195 - /tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/SenderState.java

[markt]

Author: markt
Date: Tue Sep 15 13:46:58 2015
New Revision: 1703195

URL: http://svn.apache.org/r1703195
Log:
Fix backport

Modified:

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/SenderState.java

Modified: 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/SenderState.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/SenderState.java?rev=1703195&r1=1703194&r2=1703195&view=diff
==
--- 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/SenderState.java 
(original)
+++ 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/SenderState.java 
Tue Sep 15 13:46:58 2015
@@ -16,7 +16,6 @@
  */
 package org.apache.catalina.tribes.transport;
 
-import java.util.Map;
 import java.util.concurrent.ConcurrentHashMap;
 
 import org.apache.catalina.tribes.Member;
@@ -27,7 +26,7 @@ public class SenderState {
 public static final int SUSPECT = 1;
 public static final int FAILING = 2;
 
-protected static final Map memberStates = new 
ConcurrentHashMap<>();
+protected static final ConcurrentHashMap memberStates 
= new ConcurrentHashMap<>();
 
 public static SenderState getSenderState(Member member) {
 return getSenderState(member, true);



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

svn commit: r1703196 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/tomcat/websocket/WsWebSocketContainer.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep 15 13:47:59 2015
New Revision: 1703196

URL: http://svn.apache.org/r1703196
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
Calls to backgroundProcess() may come from different threads

Modified:
tomcat/tc8.0.x/trunk/   (props changed)

tomcat/tc8.0.x/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 13:47:59 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501,1694548,1694658,1694660,1694788,1694872,1694878,169

[Bug 58384] Data race on field org.apache.tomcat.websocket.WsWebSocketContainer.backgroundProcessCount

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58384

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Mark Thomas  ---
The worst that would happen is a slight delay in WebSocket session expiration
so negative impacts for applications is unlikely.

Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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: r1703198 - in /tomcat/tc8.0.x/trunk: java/org/apache/catalina/connector/Request.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Tue Sep 15 13:55:27 2015
New Revision: 1703198

URL: http://svn.apache.org/r1703198
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58385
Fix a rare data race in the internal flag Tomcat uses to keep track of whether 
or not a request is being used for Comet processing.

Modified:
tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java
tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java?rev=1703198&r1=1703197&r2=1703198&view=diff
==
--- tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java 
(original)
+++ tomcat/tc8.0.x/trunk/java/org/apache/catalina/connector/Request.java Tue 
Sep 15 13:55:27 2015
@@ -233,9 +233,9 @@ public class Request
 
 
 /**
- * Comet state
+ * Comet state (can be accessed from multiple threads concurrently).
  */
-protected boolean comet = false;
+protected volatile boolean comet = false;
 
 
 /**

Modified: tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml?rev=1703198&r1=1703197&r2=1703198&view=diff
==
--- tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml Tue Sep 15 13:55:27 2015
@@ -95,6 +95,11 @@
 implementation on the flag that tracks if the session is new and on the
 field that tracks the maximum inactive period. (markt)
   
+  
+58385: Fix a rare data race in the internal flag Tomcat uses
+to keep track of whether or not a request is being used for Comet
+processing. (markt)
+  
 
   
   



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

[Bug 58385] Data race on field org.apache.catalina.connector.Request.comet

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58385

Mark Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Mark Thomas  ---
Fixed in trunk and 8.0.x for 8.0.27 onwards.

-- 
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

Re: RV-Predict bugs

[Mark Thomas]

On 13/09/2015 21:59, Yilong Li wrote:
> Sorry about the vague explanation. But the actual reasons are not the point
> here.

No, that is exactly the point. When you claim that something that
appears to be working without issue for many, many users then you need
to provide a justification for why there is an issue to back up the
claims you are making.

> The only thing matters is the Java memory model. And the article I
> refer to explain exactly why and how this can happen.

No, it didn't. I read that article (and parts of the JMM). While the
article did state there was a problem it did not explain why there was a
problem.

Long experience has lead us to be sceptical of bugs reported by
automated tools. When looking at such bugs and we can't see what the
problem is and the person raising the bug can't provide a clear
explanation - and continues not to provide a clear explanation when
asked for one several times - then that is the point where we start to
think the problem is with the tool.

> I agree that such non-thread-safe lazy initialization rarely causes
> problem. But, guys,

'guys' is not a gender neutral word. Do you really mean to suggest that
only the male committers look at the other issues? I tend to avoid such
phraseology where I can and use something like 'all' or 'folks' if
necessary.

> please take a look at other issues I reported. There
> are much more interesting concurrency bugs.

Yes, there are a few more interesting / likely to have an impact bugs.
The tribes issues I've fixed today look like they were reasonably likely
to cause issues.

> I am reporting these minor
> issues only because they are clearly bugs.

They are only clearly bugs once a clear explanation of the concurrency
issue that underlies many of them has been explained clearly and understood.

Opening a large number of bugs (even valid ones) without a clear
justification is not the way to win friends and influence people. It
would be far better to open a single, well explained bug, get that
accepted and fixed and then tell the community that the tool has
identified more bugs and ask the community how they would like to handle
them.

I'm still not completely happy that I understand why this is a bug. The
article Chunk provided a link to is a good start and if I make a few
assumptions about what I think the JMM means in a few places then it
does make sense. However, I'd still like to see a step-by-step guide to
how this goes wrong with references to the JMM to explain why each step
is legal.

> Mark, if you have a specific concurrency issue you would like to
> investigate, the best way is to run RV-Predict against the code that once
> revealed the problem.

I don't have any particular issues in mind, just a suspicion that
concurrency issues lie behind some of the hard to reproduce bugs that
get reported from time to time. If I could produce the bug I would have
fixed it already.

It will be interesting to see - once all these bugs have been fixed -
whether the stability of the CI test runs improves. There have been
issues around some of the async tests for example that might have a root
cause in one of these bugs.

> Even if the failure occurs rarely, RV-Predict may be
> able to identify the cause for you. I get all these race reports by running
> RV-Predict against the test suite so if the small unit test doesn't
> exercise the problematic code enough you may not get the specific answer
> you are looking for.

Once we have a test case and if concurrency issues are suspected then
I'd certainly try RV-Predict before trying to debug it manually.

Mark

> 
> Yilong
> 
> On Sun, Sep 13, 2015 at 1:30 PM, Mark Thomas  wrote:
> 
>> On 13/09/2015 19:02, Rémy Maucherat wrote:
>>> 2015-09-13 18:45 GMT+02:00 Mark Thomas :
>>>
 Yilong,

 You need to be subscribed to the dev list in order to post to it.

 On 13/09/2015 14:08, Yilong Li wrote:
> Hi Mark,
>
> On Sun, Sep 13, 2015 at 4:08 AM, Mark Thomas  > wrote:
>
> Please do not add any more RV-Predict bug reports to Bugzilla until
 the
> current set have been evaluated. To be honest it would have been
 better
> if you had paused after adding 58367-58379.
>
>
> I am going to stop here because these are all the bugs reported by
> RV-Predict in one run of the entire test suite.

 OK. Lets resolve these and then see where we stand.


>>> As far as I am concerned, I would prefer batch closing these "issues"
>>> nobody ever had.
>>
>> That is very tempting.
>>
>> Looking at the articles by the folks that are the experts in the field
>> (i.e. the authors of JSR-133) it looks like the issues raised are valid
>> - even if we don't see then very often / at all. Despite that, I'd be a
>> lot happier with a clearer explanation of what can go wrong and why/how.
>>
>> On the plus side, the issues I've looked at so far have provided
>> opportunities for clean-up in trunk.
>

[Bug 57920] websocket deadlock

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=57920

--- Comment #4 from izanm...@gmail.com ---
I'm fang the exact same issue, and can't find the culprit for this deadlock.
How did you find it?

-- 
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

buildbot success in ASF Buildbot on tomcat-8-trunk

[buildbot]

The Buildbot has detected a restored build on builder tomcat-8-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-8-trunk/builds/124

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-8-commit' 
triggered this build
Build Source Stamp: [branch tomcat/tc8.0.x/trunk] 1703196
Blamelist: markt

Build succeeded!

Sincerely,
 -The Buildbot




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

buildbot exception in ASF Buildbot on tomcat-8-trunk

[buildbot]

The Buildbot has detected a build exception on builder tomcat-8-trunk while 
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-8-trunk/builds/125

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-tomcat-8-commit' 
triggered this build
Build Source Stamp: [branch tomcat/tc8.0.x/trunk] 1703198
Blamelist: markt

BUILD FAILED: exception upload_2

Sincerely,
 -The Buildbot




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

Re: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Yilong Li]

I am not sure declaring this field as volatile is the right way to fix it
because the increment is still not atomic. If this counter doesn't have to
be precise, I think it's OK to allow data races on this field. Otherwise,
it should be declared as atomic.

Yilong

On Tue, Sep 15, 2015 at 6:43 AM,  wrote:

> Author: markt
> Date: Tue Sep 15 13:43:55 2015
> New Revision: 1703194
>
> URL: http://svn.apache.org/r1703194
> Log:
> Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
> Calls to backgroundProcess() may come from different threads
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
>
> Modified:
> tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
> URL:
> http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java?rev=1703194&r1=1703193&r2=1703194&view=diff
>
> ==
> ---
> tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
> (original)
> +++
> tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java Tue
> Sep 15 13:43:55 2015
> @@ -92,7 +92,7 @@ public class WsWebSocketContainer implem
>  private int maxBinaryMessageBufferSize =
> Constants.DEFAULT_BUFFER_SIZE;
>  private int maxTextMessageBufferSize = Constants.DEFAULT_BUFFER_SIZE;
>  private volatile long defaultMaxSessionIdleTimeout = 0;
> -private int backgroundProcessCount = 0;
> +private volatile int backgroundProcessCount = 0;
>  private int processPeriod = Constants.DEFAULT_PROCESS_PERIOD;
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

RE: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Caldarale, Charles R]

> From: Yilong Li [mailto:yilong...@runtimeverification.com] 
> Subject: Re: svn commit: r1703194 - 
> /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

> I am not sure declaring this field as volatile is the right way to fix it
> because the increment is still not atomic. If this counter doesn't have to
> be precise, I think it's OK to allow data races on this field. Otherwise,
> it should be declared as atomic.

Correct; marking the field as volatile serves no purpose here, since the value 
does not need to be precise.  Even making it atomic would not prevent multiple 
threads from iterating over the map concurrently in the backgroundProess() 
method; the only ways to prevent that are having the same lock held on the 
counter and the iteration loop, or the same lock on the counter and a busy flag.

I am concerned that the iterator in the for loop of backgroundProcess() may 
lose its validity if another thread updates the map, but I'll need to study the 
documentation and implementation to see if that's a real concern.  Regardless, 
using one of the forEach*() methods of ConcurrentHashMap would probably be more 
efficient.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Mark Thomas]

On 15/09/2015 17:30, Caldarale, Charles R wrote:
>> From: Yilong Li [mailto:yilong...@runtimeverification.com] 
>> Subject: Re: svn commit: r1703194 - 
>> /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
> 
>> I am not sure declaring this field as volatile is the right way to fix it
>> because the increment is still not atomic. If this counter doesn't have to
>> be precise, I think it's OK to allow data races on this field. Otherwise,
>> it should be declared as atomic.
> 
> Correct; marking the field as volatile serves no purpose here, since the 
> value does not need to be precise.

Using volatile does fix this issue. The odds of a data race here are
slim (to non-existent) since updates from different threads will be at
least 1s (possibly more I'd need to look at the code more closely)
apart. The use of volatile ensures that the current thread updating the
field sees the value set by the previous thread to update it.

If updates were really concurrent then I'd agree volatile is not
sufficient to fix this but that is not the case for this code.

We could switch to atomic in case the way this code is used varies over
time but I don't see that happening.

Some further comments in the code t explain the above are probably
called for.

>  Even making it atomic would not prevent multiple threads from iterating over 
> the map concurrently in the backgroundProess() method; the only ways to 
> prevent that are having the same lock held on the counter and the iteration 
> loop, or the same lock on the counter and a busy flag.

With the current code that can't happen. There is only ever one
background processor thread in existence at a time and it calls
backgroundProcess() in the same thread.

> I am concerned that the iterator in the for loop of backgroundProcess() may 
> lose its validity if another thread updates the map, but I'll need to study 
> the documentation and implementation to see if that's a real concern.  
> Regardless, using one of the forEach*() methods of ConcurrentHashMap would 
> probably be more efficient.

The Javadoc for ConcurrentHashMap says this usage is safe.

Mark


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

Re: RV-Predict bugs

[Yilong Li]

On Tue, Sep 15, 2015 at 7:19 AM, Mark Thomas  wrote:

> On 13/09/2015 21:59, Yilong Li wrote:
> > Sorry about the vague explanation. But the actual reasons are not the
> point
> > here.
>
> No, that is exactly the point. When you claim that something that
> appears to be working without issue for many, many users then you need
> to provide a justification for why there is an issue to back up the
> claims you are making.
>
> > The only thing matters is the Java memory model. And the article I
> > refer to explain exactly why and how this can happen.
>
> No, it didn't. I read that article (and parts of the JMM). While the
> article did state there was a problem it did not explain why there was a
> problem.
>
> Long experience has lead us to be sceptical of bugs reported by
> automated tools. When looking at such bugs and we can't see what the
> problem is and the person raising the bug can't provide a clear
> explanation - and continues not to provide a clear explanation when
> asked for one several times - then that is the point where we start to
> think the problem is with the tool.
>

Sorry, I should not assume that the concepts such as happens-before order
and memory model are well understood. Let's talk about how this is allowed
to happen under JMM. Consider the this example again:

if (st_200 == null ) {
st_200 = sm.getString("sc.200");
}
return st_200;

The following is a valid execution trace consists of 5 events:
T1   T2
1   READ  null
2   WRITE s
3 READ s
4 READ ???
5   READ  s

, where s is the result of sm.getString("sc.200").

T1 sees null in field st_200, initializes it, and return the initialized
value, while T2 sees a non-null value in st_200 and skips the
initialization. The question is what value T2 can read and then return in
event 4. This is addressed in JLS $17.4.5 Happens-before Order (
https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.5):

We say that a read *r* of a variable *v* is allowed to observe a write *w*
 to *v* if, in the *happens-before* partial order of the execution trace:

   -

   *r* is not ordered before *w* (i.e., it is not the case that *hb(r, w)*),
   and
   -

   there is no intervening write *w*' to *v* (i.e. no write *w*' to *v* such
   that *hb(w, w')* and *hb(w', r)*).

Informally, a read *r* is allowed to see the result of a write *w* if there
is no *happens-before* ordering to prevent that read.

The question boils down to: does the write in event 2 prevent event 4 from
reading the initial null value of st_200? No, because there is no
happens-before order involved here. So what kind of constructs introduce
happens-before order? This question is also addressed in the same section
of JLS:

It follows from the above definitions that:

   -

   An unlock on a monitor *happens-before* every subsequent lock on that
   monitor.
   -

   A write to a volatile field (§8.3.1.4
   
   ) *happens-before* every subsequent read of that field.
   -

   A call to start() on a thread *happens-before* any actions in the
   started thread.
   -

   All actions in a thread *happen-before* any other thread successfully
   returns from a join() on that thread.
   -

   The default initialization of any object *happens-before* any other
   actions (other than default-writes) of a program.


> I agree that such non-thread-safe lazy initialization rarely causes
> > problem. But, guys,
>
> 'guys' is not a gender neutral word. Do you really mean to suggest that
> only the male committers look at the other issues? I tend to avoid such
> phraseology where I can and use something like 'all' or 'folks' if
> necessary.
>

I apologize but 'guys' can be gender neutral which is what I meant.


> > please take a look at other issues I reported. There
> > are much more interesting concurrency bugs.
>
> Yes, there are a few more interesting / likely to have an impact bugs.
> The tribes issues I've fixed today look like they were reasonably likely
> to cause issues.
>
> > I am reporting these minor
> > issues only because they are clearly bugs.
>
> They are only clearly bugs once a clear explanation of the concurrency
> issue that underlies many of them has been explained clearly and
> understood.
>
> Opening a large number of bugs (even valid ones) without a clear
> justification is not the way to win friends and influence people. It
> would be far better to open a single, well explained bug, get that
> accepted and fixed and then tell the community that the tool has
> identified more bugs and ask the community how they would like to handle
> them.
>

Sorry, I wasn't aware that the community might not like that. However, I
would argue that many of the bug reports are clear enough for a Tomcat
developer to pinpoint the problem relatively easily. It has the stack
traces of the two conflicting accesses, the 

Re: svn commit: r1703177 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/membership/Membership.java webapps/docs/changelog.xml

[Felix Schumacher]

Hi Mark,

Am 15.09.2015 um 14:45 schrieb ma...@apache.org:

Author: markt
Date: Tue Sep 15 12:45:48 2015
New Revision: 1703177

URL: http://svn.apache.org/r1703177
Log:
Use single object (membersLock) for all locking
Make members volatile so single reads are safe
I am not sure, if it is enough to make members volatile. I think the 
read/write guarantees are only valid if you change the variable 
(reference) itself, not if you modify the contents of the array.


This might be a problem, if Arrays.sort sorts the array in place.

Another (old) problem might be that getMembers returns the intern array 
reference, which could be changed by the client and thus messing with 
the inner state of the class. And getMember(Member) could probably throw 
an IndexOutOfBoundException, when members would be decreased while the 
method iterates over it (probably unlikely).


Regards,
 Felix

Reduce scope of locks where possible
Expand scope of locks where necessary

Modified:
 tomcat/tc8.0.x/trunk/   (props changed)
 
tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/membership/Membership.java
 tomcat/tc8.0.x/trunk/webapps/docs/changelog.xml

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 12:45:48 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
  
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
  
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
  
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,

RE: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Caldarale, Charles R]

> From: Mark Thomas [mailto:ma...@apache.org] 
> Subject: Re: svn commit: r1703194 - 
> /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

> The odds of a data race here are slim (to non-existent)

That's definitely true; the questions arising here are more theoretical than 
practical for this particular instance.  However, they may be applicable to 
other areas.

> The use of volatile ensures that the current thread updating the
> field sees the value set by the previous thread to update it.

Ok, I misunderstood the situation - didn't realize that something else is 
preventing actual concurrent use.  But since the whole issue is based on 
multiple threads calling this method, what prevents the concurrency?  (I've 
seen threads on Linux interrupted and held up for seconds when unrelated page 
table management is underway, allowing some very unexpected data sharing.)  If 
the multiple threads that arrive here sequentially are ordered by some other 
mechanism (e.g., synchronization, context switch, termination), the volatile 
still isn't needed.

> Some further comments in the code t explain the above are probably
> called for.

That would indeed help.

> > I am concerned that the iterator in the for loop of backgroundProcess() may 
> > lose its 
> > validity if another thread updates the map

> The Javadoc for ConcurrentHashMap says this usage is safe.

The only statement I can find in the Javadoc is this:

"Similarly, Iterators, Spliterators and Enumerations return elements reflecting 
the state of the hash table at some point at or since the creation of the 
iterator/enumeration.  They do not throw ConcurrentModificationException."

Not quite the reassurance I'm looking for that an iterator will actually be 
useful (i.e., find all remaining entries) after the map has been mutated and 
possibly reorganized by another thread.  This is one spot where the C++ spec is 
clearer (rather surprisingly).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: svn commit: r1703151 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

[Felix Schumacher]

Hi Mark,

why didn't you remove the synchronization when you converted the code to 
ConcurrentLinkedDeque?


The old code had a concurrency problem, since events.size() was checked 
outside of the synchronize block. I think this is not a problem anymore, 
but I don't understand the call to events.clear() afterwards the 
while-loop in events(). We think we have guarded the queue and removed 
all entries by calling pollFirst repeatedly, so why clear it afterwards?


Regards,
 Felix


Am 15.09.2015 um 13:11 schrieb ma...@apache.org:

Author: markt
Date: Tue Sep 15 11:11:51 2015
New Revision: 1703151

URL: http://svn.apache.org/r1703151
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=58381
The list of events is accessed by multiple threads so use a thread safe Deque 
implementation.
Fix a Javadoc comment
Simplify the code a little

Modified:
 tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java?rev=1703151&r1=1703150&r2=1703151&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
Tue Sep 15 11:11:51 2015
@@ -27,9 +27,10 @@ import java.nio.channels.SelectionKey;
  import java.nio.channels.Selector;
  import java.nio.channels.ServerSocketChannel;
  import java.nio.channels.SocketChannel;
+import java.util.Deque;
  import java.util.Iterator;
-import java.util.LinkedList;
  import java.util.Set;
+import java.util.concurrent.ConcurrentLinkedDeque;
  import java.util.concurrent.atomic.AtomicReference;
  
  import org.apache.catalina.tribes.io.ObjectReader;

@@ -56,7 +57,7 @@ public class NioReceiver extends Receive
  private ServerSocketChannel serverChannel = null;
  private DatagramChannel datagramChannel = null;
  
-protected final LinkedList events = new LinkedList<>();

+protected final Deque events = new ConcurrentLinkedDeque<>();
  
  public NioReceiver() {

  }
@@ -68,8 +69,10 @@ public class NioReceiver extends Receive
  }
  
  /**

- * start cluster receiver
- * @throws IOException
+ * Start cluster receiver.
+ *
+ * @throws IOException If the receiver fails to start
+ *
   * @see org.apache.catalina.tribes.ChannelReceiver#start()
   */
  @Override
@@ -141,25 +144,33 @@ public class NioReceiver extends Receive
  
  public void addEvent(Runnable event) {

  Selector selector = this.selector.get();
-if ( selector != null ) {
+if (selector != null) {
  synchronized (events) {
  events.add(event);
  }
-if ( log.isTraceEnabled() ) log.trace("Adding event to 
selector:"+event);
-if ( isListening() ) selector.wakeup();
+if (log.isTraceEnabled()) {
+log.trace("Adding event to selector:" + event);
+}
+if (isListening()) {
+selector.wakeup();
+}
  }
  }
  
  public void events() {

-if ( events.size() == 0 ) return;
+if (events.size() == 0) {
+return;
+}
  synchronized (events) {
  Runnable r = null;
-while ( (events.size() > 0) && (r = events.removeFirst()) != null 
) {
+while ((r = events.pollFirst()) != null ) {
  try {
-if ( log.isTraceEnabled() ) log.trace("Processing event in 
selector:"+r);
+if (log.isTraceEnabled()) {
+log.trace("Processing event in selector:" + r);
+}
  r.run();
-} catch ( Exception x ) {
-log.error("",x);
+} catch (Exception x) {
+log.error("", x);
  }
  }
  events.clear();



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




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

RE: RV-Predict bugs

[Caldarale, Charles R]

> From: Yilong Li [mailto:yilong...@runtimeverification.com] 
> Subject: Re: RV-Predict bugs

> The following is a valid execution trace consists of 5 events:
> T1   T2
> 1   READ  null
> 2   WRITE s
> 3 READ s
> 4 READ ???
> 5   READ  s

> where s is the result of sm.getString("sc.200").

> The question is what value T2 can read and then return in event 4.

It's not clear what the READ ??? is intended to represent.

> The question boils down to: does the write in event 2 prevent event 4 from
> reading the initial null value of st_200?

It doesn't, but that's not the real problem.  Let's expand the example a bit:

T1   T2
1   READ  null from st_200
2a  allocate obj
2b  WRITE obj->field
2c  WRITE obj into st_200
3 READ obj from st_200
4 READ obj->field

Since there is no actual ordering of steps 2b (object initialization) and 2c 
(object publication) in T1, T2 can observe them in the reverse order and pick 
up an unitialized value for field.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

[Bug 58081] Incorrect Java version in README

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58081

--- Comment #2 from Christopher Schultz  ---
I think the Java source in there is now primarily there for historical reasons.
Does anyone actually build the Java code from the tcnative project?

-- 
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 58404] Duplicate property definitions compile.[source|target] in build.properties.default and build.xml

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58404

Christopher Schultz  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #1 from Christopher Schultz  ---
This may not be a bug: ant scripts often provide sane defaults in case the
properties files do not specify a value: it's possible to remove compile.source
for example from build.properties.default and end up confusing the compiler.

Note that ant does not allow property values to be changed once they have been
set, so the value from build.properties.default will override the default
hard-coded in build.xml.

-- 
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

Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

[Christopher Schultz]

Mark,

On 9/14/15 4:00 AM, Mark Thomas wrote:
> On 13/09/2015 23:11, Caldarale, Charles R wrote:
>>> From: ma...@apache.org [mailto:ma...@apache.org] 
>>> Subject: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: 
>>> java/org/apache/tomcat/util/http/HttpMessages.java 
>>> webapps/docs/changelog.xml
>>
>>> --- tomcat/tc8.0.x/trunk/java/org/apache/tomcat/util/http/HttpMessages.java 
>>> (original)
>>> +++ tomcat/tc8.0.x/trunk/java/org/apache/tomcat/util/http/HttpMessages.java 
>>> Sun Sep 13 20:36:40 2015
>>> @@ -69,26 +69,34 @@ public class HttpMessages {
>>>  // Does HTTP requires/allow international messages or
>>>  // are pre-defined? The user doesn't see them most of the time
>>>  switch( status ) {
>>> -case 200:
>>> -if(st_200 == null ) {
>>> -st_200 = sm.getString("sc.200");
>>> +case 200: {
>>> +String s = st_200;
>>> +if(s == null ) {
>>> +st_200 = s = sm.getString("sc.200");
>>>  }
>>> -return st_200;
>>
>> I'm not convinced this removes the data race, since there's still no 
>> guarantee that the storage writes that are part of the object initialization 
>> inside sm.getString() will be visible to another thread before the write to 
>> st_200. Shipilёv's blog has some interesting studies: 
>> http://shipilev.net/blog/2014/safe-public-construction/
> 
> OK. Let me have a read of that blog.
> 
> At the moment we have two people who claim to be expert in this area
> with different opinions on whether or not the above is safe. Personally,
> my money is on Chuck being right.

What's the reason for caching references to the return value of
sm.getString()? Is there a significant performance advantage?

-chris



signature.asc
Description: OpenPGP digital signature

Re: RV-Predict bugs

[Yilong Li]

On Tue, Sep 15, 2015 at 10:58 AM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Yilong Li [mailto:yilong...@runtimeverification.com]
> > Subject: Re: RV-Predict bugs
>
> > The following is a valid execution trace consists of 5 events:
> > T1   T2
> > 1   READ  null
> > 2   WRITE s
> > 3 READ s
> > 4 READ ???
> > 5   READ  s
>
> > where s is the result of sm.getString("sc.200").
>
> > The question is what value T2 can read and then return in event 4.
>
> It's not clear what the READ ??? is intended to represent.
>

I put ??? there because I am trying to reason about what value this read
can see. Sorry for the confusion.


>
> > The question boils down to: does the write in event 2 prevent event 4
> from
> > reading the initial null value of st_200?
>
> It doesn't, but that's not the real problem.


Well, it is the problem (at least part of it) because JLS says "Informally,
a read *r* is allowed to see the result of a write *w* if there is no
*happens-before* ordering to prevent that read." In this case, there is no
HB ordering preventing event 3 to read the initial null value put by JVM.


> Let's expand the example a bit:
>
> T1   T2
> 1   READ  null from st_200
> 2a  allocate obj
> 2b  WRITE obj->field
> 2c  WRITE obj into st_200
> 3 READ obj from st_200
> 4 READ obj->field
>
> Since there is no actual ordering of steps 2b (object initialization) and
> 2c (object publication) in T1, T2 can observe them in the reverse order and
> pick up an unitialized value for field.
>

OK, now I see what you are talking about. But consider the following
hashcode example:
public int hashCode() {
  if (hashCode == 0) {
  hashCode = computeHashCode(); // no object creation involved
  }
  return hashCode;
}

There is no object initialization/publication involved at all but the
problem still exists: this method could return 0 even if the if-statement
sees a non-zero value.

Yilong


>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

RE: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: 
> java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

> What's the reason for caching references to the return value of
> sm.getString()? Is there a significant performance advantage?

There's a whole lot of stuff going on inside that method, including string 
formatting based on locale.  Definitely not something you want to keep redoing 
for frequently used statuses.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Usage of JreVendor class

[Felix Schumacher]

Hi all,

with change r1701668 JreVendor is used in catalina.Globals. But it seems 
to be missing in tomcat-utils.jar since .../util/compat/** is not on the 
included files list.


I have tried the patch

diff --git a/build.xml b/build.xml
index 3462373..03c4270 100644
--- a/build.xml
+++ b/build.xml
@@ -348,6 +348,7 @@
   
 
 
+
 
 
 
@@ -408,6 +409,7 @@
 
 
 
+
 
 
 
@@ -2050,6 +2052,7 @@ Apache Tomcat ${version} native binaries for Win64 
AMD64/EMT64 platform.

   
   
   
+  
   
   
   

and I can start the tomcat under output/build again.

Should I commit it?

Regards,
 Felix
diff --git a/build.xml b/build.xml
index 3462373..03c4270 100644
--- a/build.xml
+++ b/build.xml
@@ -348,6 +348,7 @@
   
 
 
+
 
 
 
@@ -408,6 +409,7 @@
 
 
 
+
 
 
 
@@ -2050,6 +2052,7 @@ Apache Tomcat ${version} native binaries for Win64 AMD64/EMT64 platform.
   
   
   
+  
   
   
   


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

RE: RV-Predict bugs

[Caldarale, Charles R]

> From: Yilong Li [mailto:yilong...@runtimeverification.com] 
> Subject: Re: RV-Predict bugs

> Well, it is the problem (at least part of it) because JLS says "Informally,
> a read *r* is allowed to see the result of a write *w* if there is no
> *happens-before* ordering to prevent that read." In this case, there is no
> HB ordering preventing event 3 to read the initial null value put by JVM.

True, but as Mark previously pointed out, no one cares.  All that happens in 
that case is the object is redundantly created and then garbage collected 
later; no damage.

> But consider the following hashcode example:
> public int hashCode() {
>   if (hashCode == 0) {
>   hashCode = computeHashCode(); // no object creation involved
>   }
>   return hashCode;
> }

> There is no object initialization/publication involved at all but the
> problem still exists: this method could return 0 even if the if-statement
> sees a non-zero value.

No, it can't (unless computeHashCode() returns a zero, which presumably it 
won't).  This is all action within a single thread, and as such must obey 
intra-thread semantics (i.e., statements are executed in control flow order).
 
 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

[Bug 58411] New: CoyoteWriter throws StringIndexOutOfBoundsException when concurrently printing lines

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58411

Bug ID: 58411
   Summary: CoyoteWriter throws StringIndexOutOfBoundsException
when concurrently printing lines
   Product: Tomcat 8
   Version: 8.0.26
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: sdav...@gmail.com

I am currently opening multiple InputStreams and attempting to use println send
data through the Servlet's PrintWriter, unfortunately this sends back a
StringIndexOutOfBoundsException: String index out of range: -49
   at java.lang.String.getChars(String.java:812)
   at org.apache.tomcat.util.buf.CharChunk.append(CharChunk.java:333)
   at org.apache.catalina.connector.OuputBuffer.write(OuputBuffer.java:533)
   at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:170)
   at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:180)
   at org.apache.catalina.connector.CoyoteWriter.print(CoyoteWriter.java:238)
   at org.apache.catalina.connector.CoyoteWriter.println(CoyoteWriter.java:305)

Using PrintWriter's printf or format methods work properly since the
CoyoteWriter doesn't override those methods and the appropriate synchronized
blocks are enforced, unlike the print overrides which specifically removed the
synchronized blocks. I would suggest removing the unnecessary overrides, it
looks like the PrintWriter handles everything the CoyoteWriter is doing. I
checked the history on the 8.x branch for the file and there isn't a reason why
the class was ever needed in the first place.

-- 
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

Re: RV-Predict bugs

[Yilong Li]

On Tue, Sep 15, 2015 at 11:32 AM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Yilong Li [mailto:yilong...@runtimeverification.com]
> > Subject: Re: RV-Predict bugs
>
> > Well, it is the problem (at least part of it) because JLS says
> "Informally,
> > a read *r* is allowed to see the result of a write *w* if there is no
> > *happens-before* ordering to prevent that read." In this case, there is
> no
> > HB ordering preventing event 3 to read the initial null value put by JVM.
>
> True, but as Mark previously pointed out, no one cares.  All that happens
> in that case is the object is redundantly created and then garbage
> collected later; no damage.
>

No, it's not right. It's possible (although very unlikely) that this method
could return null and results in a null pointer exception later.


>
> > But consider the following hashcode example:
> > public int hashCode() {
> >   if (hashCode == 0) {
> >   hashCode = computeHashCode(); // no object creation involved
> >   }
> >   return hashCode;
> > }
>
> > There is no object initialization/publication involved at all but the
> > problem still exists: this method could return 0 even if the if-statement
> > sees a non-zero value.
>
> No, it can't (unless computeHashCode() returns a zero, which presumably it
> won't).  This is all action within a single thread, and as such must obey
> intra-thread semantics (i.e., statements are executed in control flow
> order).
>

Yes, it can. You probably misunderstand intra-thread semantics.
Intra-thread semantics says that event 3 (the first read of the field
hashCode) happens before event 4 (the second read of field hashCode) but it
has no effect on the value event 4 can see (because event 3 is also a read
rather than a write).

Yilong


>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

[Bug 58412] New: AsyncFileHandler logs package and method name as null.null

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58412

Bug ID: 58412
   Summary: AsyncFileHandler logs package and method name as
null.null
   Product: Tomcat 8
   Version: trunk
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: felix.schumac...@internetallee.de

Created attachment 33110
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33110&action=edit
Resolve method and class name before handing the record into the queue

When using AsyncFileHandler it sometimes happens, that package and method names
are resolved to null, whenn logging.

It is described on stackoverflow
http://stackoverflow.com/questions/27117369/generic-java-logger-output-null-null-for-class-and-member-name

The attached patch fixes it in my tests.

-- 
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 58411] CoyoteWriter throws StringIndexOutOfBoundsException when concurrently printing lines

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58411

Remy Maucherat  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #1 from Remy Maucherat  ---
Concurrent writes (or reads ...) are not allowed, add synchronization.

-- 
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

Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

[Christopher Schultz]

Chuck,

On 9/15/15 2:21 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
>> Subject: Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: 
>> java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml
> 
>> What's the reason for caching references to the return value of
>> sm.getString()? Is there a significant performance advantage?
> 
> There's a whole lot of stuff going on inside that method, including
> string formatting based on locale.  Definitely not something you want
> to keep redoing for frequently used statuses.

No string formatting, and the Locale should have already resolved by the
time the first call was made to StringManager.getString.

For a PropertyResourceBundle, this amounts to the same amount of work as
HashMap.get(). (Though it might actually be Hashtable.get, which is a
bit slower).

So yes, it's nice to cache this value but I'm interested to see
performance numbers. Did anyone do a benchmark already?

The way to remove race conditions from this code is to cache the values
upon construction of the HttpMessages object, of course. I haven't yet
read that blog post but I suspect it says that when possible, prefer
doing one-time operations in constructors instead of using lazy
initialization. In the case of this class, it seems that lazy
initialization doesn't really buy us anything: those strings will be
loaded eventually anyway.

-chris



signature.asc
Description: OpenPGP digital signature

[Bug 58284] StandardSession attempts to silently write NonSerializable objects

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58284

--- Comment #9 from Andrew Shore  ---
Hey sorry the the delay in response. I was out of the office last week and
haven't had a chance to start this. How soon is soon? I probably won't be able
to get to this until later in the week.

-- 
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 58411] CoyoteWriter throws StringIndexOutOfBoundsException when concurrently printing lines

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58411

--- Comment #2 from sdav...@gmail.com ---
Yes, that's what I did end up doing but it seems odd that Tomcat would
specifically remove the appropriate synchronization provided by the
PrintWriter, so my code that was working on Jetty doesn't work in Tomcat both
programming to the Servlet spec - one would think it would be a transparent
change. Is it even documented that Tomcat doesn't handle concurrent writes? Was
there a reason for adding this seemingly arbitrary restriction?

-- 
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

RE: RV-Predict bugs

[Caldarale, Charles R]

> From: Yilong Li [mailto:yilong...@runtimeverification.com] 
> Subject: Re: RV-Predict bugs

> > True, but as Mark previously pointed out, no one cares.  All that happens
> > in that case is the object is redundantly created and then garbage
> > collected later; no damage.

> No, it's not right. It's possible (although very unlikely) that this method
> could return null and results in a null pointer exception later.

Again, that cannot happen; see below.

> Intra-thread semantics says that event 3 (the first read of the field
> hashCode) happens before event 4 (the second read of field hashCode) but it
> has no effect on the value event 4 can see (because event 3 is also a read
> rather than a write).

You're mixing up inter- and intra-thread semantics and completely ignoring the 
write to hashCode when the initially observed value is zero.  Intra-thread 
semantics require that operations occur in program order, so the initial zero 
(or null) check results in a non-zero (or non-null) write to the field of 
interest; control flow cannot be ignored here.  If your supposition were 
correct, a compiler (or CPU) would be free to migrate actions dependent on a 
conditional block to a spot prior to that conditional block - clearly that is 
nonsense.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: RV-Predict bugs

[Christopher Schultz]

Yilong,

On 9/15/15 12:59 PM, Yilong Li wrote:
> On Tue, Sep 15, 2015 at 7:19 AM, Mark Thomas  wrote:
> 
>> On 13/09/2015 21:59, Yilong Li wrote:
>>> Sorry about the vague explanation. But the actual reasons are not the
>> point
>>> here.
>>
>> No, that is exactly the point. When you claim that something that
>> appears to be working without issue for many, many users then you need
>> to provide a justification for why there is an issue to back up the
>> claims you are making.
>>
>>> The only thing matters is the Java memory model. And the article I
>>> refer to explain exactly why and how this can happen.
>>
>> No, it didn't. I read that article (and parts of the JMM). While the
>> article did state there was a problem it did not explain why there was a
>> problem.
>>
>> Long experience has lead us to be sceptical of bugs reported by
>> automated tools. When looking at such bugs and we can't see what the
>> problem is and the person raising the bug can't provide a clear
>> explanation - and continues not to provide a clear explanation when
>> asked for one several times - then that is the point where we start to
>> think the problem is with the tool.
>>
> 
> Sorry, I should not assume that the concepts such as happens-before order
> and memory model are well understood. Let's talk about how this is allowed
> to happen under JMM. Consider the this example again:
> 
> if (st_200 == null ) {
> st_200 = sm.getString("sc.200");
> }
> return st_200;
> 
> The following is a valid execution trace consists of 5 events:
> T1   T2
> 1   READ  null
> 2   WRITE s
> 3 READ s
> 4 READ ???
> 5   READ  s
> 
> , where s is the result of sm.getString("sc.200").
> 
> T1 sees null in field st_200, initializes it, and return the initialized
> value, while T2 sees a non-null value in st_200 and skips the
> initialization. The question is what value T2 can read and then return in
> event 4. This is addressed in JLS $17.4.5 Happens-before Order (
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.5):

I think you are mistaking the above code with something more like this:

private String s;

public String getString()
{
  if(null == s)
s = new String("foo");

   return s;
}

In the above case, the reference "s" may for a short time be a reference
to an uninitialized object of type String. This can be problematic.
Imagine the psusdo-bytecode below generated by the compiler:

1:   push s
3:   ifnull goto 8
5:   goto X
8:   new java.lang.String
10:  dup
11:  store s
13:  push "foo"
15:  call java.lang.String.

If T1 executes the instruction on line 11 and then T2 sees that
reference before T1 gets a change to call the String constructor, it's a
mess.

But, since the initialization of the String coming from
StringManager.getString is fully-constructed before any assignment can
take place, this is completely safe.

As Mark said, reference assignment is guaranteed to be atomic, so T1
while and T2 can disagree about the value of s, it will never be true
that either thread sees s as non-null but also not yet initialized.

In this particular case, the race condition does in fact exist, but
nobody cares: if s gets initialized more than once (to the same value,
in fact), it's no harm to the running program. Even if the values were
different (e.g. ResourceBundle hands-out String values that aren't
consistent), it wouldn't matter to client code.

I'm having trouble understanding Chuck's parallel response to this. :/

-chris



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

[Mark Thomas]

On 15/09/2015 19:51, Christopher Schultz wrote:
> Chuck,
> 
> On 9/15/15 2:21 PM, Caldarale, Charles R wrote:
>>> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
>>> Subject: Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: 
>>> java/org/apache/tomcat/util/http/HttpMessages.java 
>>> webapps/docs/changelog.xml
>>
>>> What's the reason for caching references to the return value of
>>> sm.getString()? Is there a significant performance advantage?
>>
>> There's a whole lot of stuff going on inside that method, including
>> string formatting based on locale.  Definitely not something you want
>> to keep redoing for frequently used statuses.
> 
> No string formatting, and the Locale should have already resolved by the
> time the first call was made to StringManager.getString.
> 
> For a PropertyResourceBundle, this amounts to the same amount of work as
> HashMap.get(). (Though it might actually be Hashtable.get, which is a
> bit slower).
> 
> So yes, it's nice to cache this value but I'm interested to see
> performance numbers. Did anyone do a benchmark already?

Yes, I did a micro benchmark on that code. I even committed it so you
could have run the test yourself in less time that it took to wrote tis
e-mail.

The cached String values are returned approximately 2 orders of
magnitude faster. OK we are talking about 10s of nano-seconds vs.
fractions of nanoseconds so it is almost certainly in the noise but I
couldn't see a good reason to drop the cache and make things
fractionally slower for every request.

> 
> The way to remove race conditions from this code is to cache the values
> upon construction of the HttpMessages object, of course.

And if you look at the latest version of that class you see ... ?

Mark


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

Re: svn commit: r1703177 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/membership/Membership.java webapps/docs/changelog.xml

[Mark Thomas]

On 15/09/2015 18:28, Felix Schumacher wrote:
> Hi Mark,
> 
> Am 15.09.2015 um 14:45 schrieb ma...@apache.org:
>> Author: markt
>> Date: Tue Sep 15 12:45:48 2015
>> New Revision: 1703177
>>
>> URL: http://svn.apache.org/r1703177
>> Log:
>> Use single object (membersLock) for all locking
>> Make members volatile so single reads are safe
> I am not sure, if it is enough to make members volatile. I think the
> read/write guarantees are only valid if you change the variable
> (reference) itself, not if you modify the contents of the array.
> 
> This might be a problem, if Arrays.sort sorts the array in place.

Correct. I took the comments in the previous code at face value and
assumed that Arrays.sort() would be applied before setting members. A
quick look shows that isn't the case. I'll do a quick review of the code
for similar issues and get them fixed.

> Another (old) problem might be that getMembers returns the intern array
> reference, which could be changed by the client and thus messing with
> the inner state of the class. And getMember(Member) could probably throw
> an IndexOutOfBoundException, when members would be decreased while the
> method iterates over it (probably unlikely).

I think we can live with that. Fixing it would require defensive copies
or changing the API to use, for example, a read-only list. In think
either of those options would be too expensive.

Mark


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

Re: RV-Predict bugs

[Christopher Schultz]

Chuck,

On 9/15/15 3:06 PM, Caldarale, Charles R wrote:
>> From: Yilong Li [mailto:yilong...@runtimeverification.com] 
>> Subject: Re: RV-Predict bugs
> 
>>> True, but as Mark previously pointed out, no one cares.  All that happens
>>> in that case is the object is redundantly created and then garbage
>>> collected later; no damage.
> 
>> No, it's not right. It's possible (although very unlikely) that this method
>> could return null and results in a null pointer exception later.
> 
> Again, that cannot happen; see below.
> 
>> Intra-thread semantics says that event 3 (the first read of the field
>> hashCode) happens before event 4 (the second read of field hashCode) but it
>> has no effect on the value event 4 can see (because event 3 is also a read
>> rather than a write).
> 
> You're mixing up inter- and intra-thread semantics and completely
> ignoring the write to hashCode when the initially observed value is
> zero.  Intra-thread semantics require that operations occur in
> program order, so the initial zero (or null) check results in a
> non-zero (or non-null) write to the field of interest; control flow
> cannot be ignored here.  If your supposition were correct, a compiler
> (or CPU) would be free to migrate actions dependent on a conditional
> block to a spot prior to that conditional block - clearly that is
> nonsense.

I haven't read much about this in many years, but when I was reading
everything surrounding the whole DCL debacle years ago, I discovered
that within a synchronized block, the JIT is allowed to re-order
statements if it determines it is safe to do so -- and that statements
that occur before the memory barrier must not be interleaved with
statements inside the block, and likewise, nothing after the block can
be moved "inside" that block.

I'm not sure what that means these days (years later, with changes to
the JMM (which are presumably backward-compatible) and lots of other
things) and I'm not sure if/how that affects code that has no
synchronized block.

But it seems reasonable that the JIT would be allowed to perform some
otherwise "conditional" code execution *before* the condition is
actually evaluated, as long as that code doesn't have any side-effects
(such as assignment of the return value of, say, hashCode() or
StringManager.getString()). The JIT is free to "waste" the CPUs time on
a bet that the conditional branch will be reached, but can discard that
work if the conditional branch is skipped. I'm sure the rules for
"side-effects" include calling methods not yet proven to have any
side-effects which might be a giant rathole that nobody has decided to
jump into, and therefore method calls are always considered "side
effects" just to keep things safe and simple.

-chris



signature.asc
Description: OpenPGP digital signature

Re: RV-Predict bugs

[Christopher Schultz]

All,

On 9/15/15 3:07 PM, Christopher Schultz wrote:
> In the above case, the reference "s" may for a short time be a reference
> to an uninitialized object of type String. This can be problematic.
> Imagine the psusdo-bytecode below generated by the compiler:
> 
> 1:   push s
> 3:   ifnull goto 8
> 5:   goto X

This line should have of course been "goto 17"

> 8:   new java.lang.String
> 10:  dup
> 11:  store s
> 13:  push "foo"
> 15:  call java.lang.String.

... and of course

17: push s
19: return

Sorry for the sloppy (fake!) code.

-chris



signature.asc
Description: OpenPGP digital signature

RE: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: 
> java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

> > There's a whole lot of stuff going on inside that method, including
> > string formatting based on locale.  Definitely not something you want
> > to keep redoing for frequently used statuses.

> No string formatting, and the Locale should have already resolved by the
> time the first call was made to StringManager.getString.

You're presuming that java.util.ResourceBundle has been implemented the way 
you'd like and doesn't use weak references or something similar.  But yes, in 
the typical case, this shouldn't be much more than a map lookup.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

[Bug 58411] CoyoteWriter throws StringIndexOutOfBoundsException when concurrently printing lines

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58411

--- Comment #3 from Christopher Schultz  ---
It's worth pointing-out that nowhere in java.io.PrintWriter does it say
anything about being thread-safe, nor does its superclass, java.io.Writer.
Also, none of the methods are synchronized.

Internally to these methods, there are synchronized blocks but that seems to be
an implementation detail.

If the CoyoteWriter is not thread-safe, it should probably documented as such,
but it's completely reasonable to leave it without synchronization: adding the
overhead of synchronization to every write() would be unreasonable for what is
usually a rare use-case.

You are already having to manage your threads to ensure that you write things
to the response in the right order (right?) so you may as well use that same
mechanism to provide thread-safety to your use of CoyoteWriter.

A better method of communication would be to queue your writes (using a
thread-safe queue) and have a single thread write to the response output
stream. Right now, it sounds like the wild west in your code.

-- 
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

Re: RV-Predict bugs

[Mark Thomas]

On 15/09/2015 17:59, Yilong Li wrote:
> On Tue, Sep 15, 2015 at 7:19 AM, Mark Thomas  wrote:

>> Long experience has lead us to be sceptical of bugs reported by
>> automated tools. When looking at such bugs and we can't see what the
>> problem is and the person raising the bug can't provide a clear
>> explanation - and continues not to provide a clear explanation when
>> asked for one several times - then that is the point where we start to
>> think the problem is with the tool.
>>
> 
> Sorry, I should not assume that the concepts such as happens-before order
> and memory model are well understood. Let's talk about how this is allowed
> to happen under JMM. Consider the this example again:
> 
> if (st_200 == null ) {
> st_200 = sm.getString("sc.200");
> }
> return st_200;
> 
> The following is a valid execution trace consists of 5 events:
> T1   T2
> 1   READ  null
> 2   WRITE s
> 3 READ s
> 4 READ ???
> 5   READ  s
> 
> , where s is the result of sm.getString("sc.200").
> 
> T1 sees null in field st_200, initializes it, and return the initialized
> value, while T2 sees a non-null value in st_200 and skips the
> initialization. The question is what value T2 can read and then return in
> event 4. This is addressed in JLS $17.4.5 Happens-before Order (
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.5):
> 
> We say that a read *r* of a variable *v* is allowed to observe a write *w*
> to *v* if, in the *happens-before* partial order of the execution trace:
> 
>-
> 
>*r* is not ordered before *w* (i.e., it is not the case that *hb(r, w)*),
>and
>-
> 
>there is no intervening write *w*' to *v* (i.e. no write *w*' to *v* such
>that *hb(w, w')* and *hb(w', r)*).
> 
> Informally, a read *r* is allowed to see the result of a write *w* if there
> is no *happens-before* ordering to prevent that read.
> 
> The question boils down to: does the write in event 2 prevent event 4 from
> reading the initial null value of st_200? No, because there is no
> happens-before order involved here. So what kind of constructs introduce
> happens-before order? This question is also addressed in the same section
> of JLS:
> 
> It follows from the above definitions that:
> 
>-
> 
>An unlock on a monitor *happens-before* every subsequent lock on that
>monitor.
>-
> 
>A write to a volatile field (§8.3.1.4
>
>) *happens-before* every subsequent read of that field.
>-
> 
>A call to start() on a thread *happens-before* any actions in the
>started thread.
>-
> 
>All actions in a thread *happen-before* any other thread successfully
>returns from a join() on that thread.
>-
> 
>The default initialization of any object *happens-before* any other
>actions (other than default-writes) of a program.

Thank you. That helps fill in a few gaps. Putting it into my own words
to check my understanding:

- The two reads in T2 may be re-ordered because, in T2, there is nothing
  that requires a happens-before relationship between the two reads

- If T2 was executing in isolation the order of the reads wouldn't
  matter

- However, T1 is writing.

So if the writes in T2 are re-ordered and the write from T1 takes place
between them the T2 read for the line 'st_200 == null' could return a
non-null value for st_200 (the value after the write from T1) while the
read for the line 'return st_200;' could return null (the value from
before the write in T1).

Is my understanding correct?

>> I don't have any particular issues in mind, just a suspicion that
>> concurrency issues lie behind some of the hard to reproduce bugs that
>> get reported from time to time. If I could produce the bug I would have
>> fixed it already.
>>
> 
> Technically speaking, RV-Predict doesn't require a developer to be able to
> produce the bug or data race in order to detect it. One can run RV-Predict
> on code that fails only intermittently and RV-Predict may still catch the
> bug. Perhaps it can be helpful to ask the bug reporter to run their code
> against RV-Predict if it's just too hard to extract a test case that can
> reproduce the failure consistently enough.

Good to know. That is certainly worth a try. I'll add something to the
bugs in question.

> Thanks again for the prompt responses and the quick fixes of the reported
> bugs. This has also helped RV-Predict to get into a better shape.

Thanks to you to. It has certainly helped Tomcat improve and the
discussion around these issues continues to help educate the community
as a whole about these issues.

Mark


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

[Bug 58284] StandardSession attempts to silently write NonSerializable objects

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58284

--- Comment #10 from Mark Thomas  ---
You probably have a day or two. I'll update the bug when I reach the point
where I need the patch. If you can update it as well when you start work we
should be able to avoid duplicating effort.

-- 
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 58284] StandardSession attempts to silently write NonSerializable objects

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58284

--- Comment #11 from Andrew Shore  ---
Will do. Thanks Mark.

-- 
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

Re: svn commit: r1703177 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/membership/Membership.java webapps/docs/changelog.xml

[Mark Thomas]

On 15/09/2015 20:15, Mark Thomas wrote:
> On 15/09/2015 18:28, Felix Schumacher wrote:
>> Hi Mark,
>>
>> Am 15.09.2015 um 14:45 schrieb ma...@apache.org:
>>> Author: markt
>>> Date: Tue Sep 15 12:45:48 2015
>>> New Revision: 1703177
>>>
>>> URL: http://svn.apache.org/r1703177
>>> Log:
>>> Use single object (membersLock) for all locking
>>> Make members volatile so single reads are safe
>> I am not sure, if it is enough to make members volatile. I think the
>> read/write guarantees are only valid if you change the variable
>> (reference) itself, not if you modify the contents of the array.
>>
>> This might be a problem, if Arrays.sort sorts the array in place.
> 
> Correct. I took the comments in the previous code at face value and
> assumed that Arrays.sort() would be applied before setting members. A
> quick look shows that isn't the case. I'll do a quick review of the code
> for similar issues and get them fixed.
> 
>> Another (old) problem might be that getMembers returns the intern array
>> reference, which could be changed by the client and thus messing with
>> the inner state of the class. And getMember(Member) could probably throw
>> an IndexOutOfBoundException, when members would be decreased while the
>> method iterates over it (probably unlikely).
> 
> I think we can live with that. Fixing it would require defensive copies
> or changing the API to use, for example, a read-only list. In think
> either of those options would be too expensive.

Hmm. Looking through the code I can't actually see why we even need the
ordering. The only places where getMemberAliveTime() is called is in the
comparator and in memberAlive() when the updates take place.

Given that, I think we just remove the ordering and the associated
comparator.

Mark


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

Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

[Christopher Schultz]

Mark,

On 9/15/15 3:09 PM, Mark Thomas wrote:
> On 15/09/2015 19:51, Christopher Schultz wrote:
>> Chuck,
>>
>> On 9/15/15 2:21 PM, Caldarale, Charles R wrote:
 From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
 Subject: Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: 
 java/org/apache/tomcat/util/http/HttpMessages.java 
 webapps/docs/changelog.xml
>>>
 What's the reason for caching references to the return value of
 sm.getString()? Is there a significant performance advantage?
>>>
>>> There's a whole lot of stuff going on inside that method, including
>>> string formatting based on locale.  Definitely not something you want
>>> to keep redoing for frequently used statuses.
>>
>> No string formatting, and the Locale should have already resolved by the
>> time the first call was made to StringManager.getString.
>>
>> For a PropertyResourceBundle, this amounts to the same amount of work as
>> HashMap.get(). (Though it might actually be Hashtable.get, which is a
>> bit slower).
>>
>> So yes, it's nice to cache this value but I'm interested to see
>> performance numbers. Did anyone do a benchmark already?
> 
> Yes, I did a micro benchmark on that code. I even committed it so you
> could have run the test yourself in less time that it took to wrote tis
> e-mail.

:p

> The cached String values are returned approximately 2 orders of
> magnitude faster. OK we are talking about 10s of nano-seconds vs.
> fractions of nanoseconds so it is almost certainly in the noise but I
> couldn't see a good reason to drop the cache and make things
> fractionally slower for every request.

Agreed. Doing work where no work is required is called waste :) If the
alternative was some overly-complicated mess of code, it would be worth
it to take the small performance hit in favor of maintainability. In
this case, the code is entirely straightforward.

>> The way to remove race conditions from this code is to cache the values
>> upon construction of the HttpMessages object, of course.
> 
> And if you look at the latest version of that class you see ... ?

Nothing. HttpMessages is gone from trunk.

Checking 8.0 HEAD shows the problem has been resolved, but I still agree
that there was only a theoretical and not an actual problem here in the
first place. I like the new implementation because it's faster and,
honestly, a bit more straightforward.

In general, I'm not a big fan of lazy initialization unless there is a
significant advantage to delaying the work or there is a very good
likelihood that the work will never actually need to be done.

When the work produces a hug object graph, I like to use WeakReferences
so that the graph can be discarded under memory pressure and re-created
multiple times during a long-running process.

-chris



signature.asc
Description: OpenPGP digital signature

RE: RV-Predict bugs

[Caldarale, Charles R]

> From: Mark Thomas [mailto:ma...@apache.org] 
> Subject: Re: RV-Predict bugs

> Putting it into my own words to check my understanding:

> - The two reads in T2 may be re-ordered because, in T2, there is nothing
>   that requires a happens-before relationship between the two reads

Depends on what was really meant by the ??? notation.  If it were another 
reference to st_200, then the example ignores the potential write to st_200.

> - If T2 was executing in isolation the order of the reads wouldn't
>   matter

Correct, assuming there is no write in T2's control flow.

> - However, T1 is writing.

> So if the writes

I'll assume you meant "reads" there.

> in T2 are re-ordered and the write from T1 takes place between them the T2 
> read for the line 'st_200 == null' could return a non-null value for st_200 
> (the value after the write from T1) while the read for the line 'return 
> st_200;' could return null (the value from before the write in T1).

No - that would violate program order (intra-thread semantics).  The compiler 
cannot legally move the read for "return st_200" to a point before the 
potential write to st_200.  The CPU can speculatively read for the return 
value, but must discard such speculation if a write were to occur (or use store 
forwarding to update the read).
 
 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: RV-Predict bugs

[Christopher Schultz]

Mark,

On 9/15/15 3:29 PM, Mark Thomas wrote:
> On 15/09/2015 17:59, Yilong Li wrote:
>> On Tue, Sep 15, 2015 at 7:19 AM, Mark Thomas  wrote:
> 
>>> Long experience has lead us to be sceptical of bugs reported by
>>> automated tools. When looking at such bugs and we can't see what the
>>> problem is and the person raising the bug can't provide a clear
>>> explanation - and continues not to provide a clear explanation when
>>> asked for one several times - then that is the point where we start to
>>> think the problem is with the tool.
>>>
>>
>> Sorry, I should not assume that the concepts such as happens-before order
>> and memory model are well understood. Let's talk about how this is allowed
>> to happen under JMM. Consider the this example again:
>>
>> if (st_200 == null ) {
>> st_200 = sm.getString("sc.200");
>> }
>> return st_200;
>>
>> The following is a valid execution trace consists of 5 events:
>> T1   T2
>> 1   READ  null
>> 2   WRITE s
>> 3 READ s
>> 4 READ ???
>> 5   READ  s
>>
>> , where s is the result of sm.getString("sc.200").
>>
>> T1 sees null in field st_200, initializes it, and return the initialized
>> value, while T2 sees a non-null value in st_200 and skips the
>> initialization. The question is what value T2 can read and then return in
>> event 4. This is addressed in JLS $17.4.5 Happens-before Order (
>> https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.5):
>>
>> We say that a read *r* of a variable *v* is allowed to observe a write *w*
>> to *v* if, in the *happens-before* partial order of the execution trace:
>>
>>-
>>
>>*r* is not ordered before *w* (i.e., it is not the case that *hb(r, w)*),
>>and
>>-
>>
>>there is no intervening write *w*' to *v* (i.e. no write *w*' to *v* such
>>that *hb(w, w')* and *hb(w', r)*).
>>
>> Informally, a read *r* is allowed to see the result of a write *w* if there
>> is no *happens-before* ordering to prevent that read.
>>
>> The question boils down to: does the write in event 2 prevent event 4 from
>> reading the initial null value of st_200? No, because there is no
>> happens-before order involved here. So what kind of constructs introduce
>> happens-before order? This question is also addressed in the same section
>> of JLS:
>>
>> It follows from the above definitions that:
>>
>>-
>>
>>An unlock on a monitor *happens-before* every subsequent lock on that
>>monitor.
>>-
>>
>>A write to a volatile field (§8.3.1.4
>>
>>) *happens-before* every subsequent read of that field.
>>-
>>
>>A call to start() on a thread *happens-before* any actions in the
>>started thread.
>>-
>>
>>All actions in a thread *happen-before* any other thread successfully
>>returns from a join() on that thread.
>>-
>>
>>The default initialization of any object *happens-before* any other
>>actions (other than default-writes) of a program.
> 
> Thank you. That helps fill in a few gaps. Putting it into my own words
> to check my understanding:
> 
> - The two reads in T2 may be re-ordered because, in T2, there is nothing
>   that requires a happens-before relationship between the two reads
> 
> - If T2 was executing in isolation the order of the reads wouldn't
>   matter
> 
> - However, T1 is writing.
> 
> So if the writes in T2 are re-ordered and the write from T1 takes place
> between them the T2 read for the line 'st_200 == null' could return a
> non-null value for st_200 (the value after the write from T1) while the
> read for the line 'return st_200;' could return null (the value from
> before the write in T1).
> 
> Is my understanding correct?

That sounds crazy (but may actually be correct).

I don't see why a thread would read one value from memory and then have
that value change locally without going back to main memory. T1 can only
affect its own local views of the references and, of course, main
memory. Once T1 writes to main memory, T2 can see the changes. I don't
think the JMM allows threads to change other threads' references
directly without writing to main memory.

I don't think that T2 can read non-null and then later read null given
the code we are discussing. If T1 writes /null/ to main memory, then
this can happen,but I think we can all agree T1 is *not* gong to write null.

>>> I don't have any particular issues in mind, just a suspicion that
>>> concurrency issues lie behind some of the hard to reproduce bugs that
>>> get reported from time to time. If I could produce the bug I would have
>>> fixed it already.
>>>
>>
>> Technically speaking, RV-Predict doesn't require a developer to be able to
>> produce the bug or data race in order to detect it. One can run RV-Predict
>> on code that fails only intermittently and RV-Predict may still catch the
>> bug. Perhaps it can be helpful t

Re: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Mark Thomas]

On 15/09/2015 18:35, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org] 
>> Subject: Re: svn commit: r1703194 - 
>> /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
> 
>> The odds of a data race here are slim (to non-existent)
> 
> That's definitely true; the questions arising here are more theoretical than 
> practical for this particular instance.  However, they may be applicable to 
> other areas.
> 
>> The use of volatile ensures that the current thread updating the
>> field sees the value set by the previous thread to update it.
> 
> Ok, I misunderstood the situation - didn't realize that something else is 
> preventing actual concurrent use.  But since the whole issue is based on 
> multiple threads calling this method, what prevents the concurrency?  (I've 
> seen threads on Linux interrupted and held up for seconds when unrelated page 
> table management is underway, allowing some very unexpected data sharing.)  
> If the multiple threads that arrive here sequentially are ordered by some 
> other mechanism (e.g., synchronization, context switch, termination), the 
> volatile still isn't needed.

What prevents the concurrency is that there is only ever one background
thread. The only was I see this happening is:
- T1 runs and expires all the current sessions.
- The container unregisters itself from background processing since it
  has no sessions
- It was the only thing registered for background processing so the
  T1 is terminated by the BackgroundProcessManager
- A new WeBSoket session is opened
- The container registers itself with the BackgroundProcessManager
- A new background processing thread T2 is started
- T2 runs

RV-Predict indicated that there was a race. Was this a false positive?
The overhead associated with using volatile is minimal but I'd be happy
to drop it if it is not necessary.


>> Some further comments in the code t explain the above are probably
>> called for.
> 
> That would indeed help.
> 
>>> I am concerned that the iterator in the for loop of backgroundProcess() may 
>>> lose its 
>>> validity if another thread updates the map
> 
>> The Javadoc for ConcurrentHashMap says this usage is safe.
> 
> The only statement I can find in the Javadoc is this:
> 
> "Similarly, Iterators, Spliterators and Enumerations return elements 
> reflecting the state of the hash table at some point at or since the creation 
> of the iterator/enumeration.  They do not throw 
> ConcurrentModificationException."
> 
> Not quite the reassurance I'm looking for that an iterator will actually be 
> useful (i.e., find all remaining entries) after the map has been mutated and 
> possibly reorganized by another thread.  This is one spot where the C++ spec 
> is clearer (rather surprisingly).

I was looking at keyset

"they are guaranteed to traverse elements as they existed upon
construction exactly once, and may (but are not guaranteed to) reflect
any modifications subsequent to construction."

Mark


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

Re: svn commit: r1703151 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

[Mark Thomas]

On 15/09/2015 18:41, Felix Schumacher wrote:
> Hi Mark,
> 
> why didn't you remove the synchronization when you converted the code to
> ConcurrentLinkedDeque?

No idea. Focusing on one thing and missing the obvious I suspect.

> The old code had a concurrency problem, since events.size() was checked
> outside of the synchronize block. I think this is not a problem anymore,
> but I don't understand the call to events.clear() afterwards the
> while-loop in events(). We think we have guarded the queue and removed
> all entries by calling pollFirst repeatedly, so why clear it afterwards?

Don't know. I'll take another look and clean it up some more.

Mark

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

Re: svn commit: r1702821 - in /tomcat/tc8.0.x/trunk: java/org/apache/tomcat/util/http/HttpMessages.java webapps/docs/changelog.xml

[Mark Thomas]

On 15/09/2015 20:37, Christopher Schultz wrote:
> On 9/15/15 3:09 PM, Mark Thomas wrote:



>> The cached String values are returned approximately 2 orders of
>> magnitude faster. OK we are talking about 10s of nano-seconds vs.
>> fractions of nanoseconds so it is almost certainly in the noise but I
>> couldn't see a good reason to drop the cache and make things
>> fractionally slower for every request.
> 
> Agreed. Doing work where no work is required is called waste :) If the
> alternative was some overly-complicated mess of code, it would be worth
> it to take the small performance hit in favor of maintainability. In
> this case, the code is entirely straightforward.
> 
>>> The way to remove race conditions from this code is to cache the values
>>> upon construction of the HttpMessages object, of course.
>>
>> And if you look at the latest version of that class you see ... ?
> 
> Nothing. HttpMessages is gone from trunk.

:)

> Checking 8.0 HEAD shows the problem has been resolved, but I still agree
> that there was only a theoretical and not an actual problem here in the
> first place. I like the new implementation because it's faster and,
> honestly, a bit more straightforward.

I prefer the cleaner code too.

At the moment I think there was an issue but I'm watching the discussion
between those that have a better understanding of this issue than I do
with a great deal of interest. I'm certainly learning a lot just from
reading along.

> In general, I'm not a big fan of lazy initialization unless there is a
> significant advantage to delaying the work or there is a very good
> likelihood that the work will never actually need to be done.

+1

What makes some of the Tomcat code interesting is optimisations that
made sense back in the days of Tomcat 4 (Java 1.3) may not apply today.

> When the work produces a hug object graph, I like to use WeakReferences
> so that the graph can be discarded under memory pressure and re-created
> multiple times during a long-running process.

Makes sense. I can't think of anything like that off-hand in Tomcat but
+1 to the idea. Hmm. Some of the HTTP/2 priority stuff looks a bit like
that. Something to keep in mind...

Thanks.

Mark


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

RE: RV-Predict bugs

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: RV-Predict bugs

> I don't see why a thread would read one value from memory and then have
> that value change locally without going back to main memory.

The point that was trying to be made was that independent reads could be issued 
for the field, and that those reads are not necessarily ordered.  This would 
allow the second (in program order) read to observe an older value for the 
field.  However, that argument ignored the fact that if the first read observed 
a null (or zero), it would trigger action that invalidated the second read.  
The compiler (JIT) cannot move the second read to a spot prior to the first due 
to the potential of an intervening write.  An x86 CPU could move the read, but, 
if the write occurred, store forwarding would be used to update the second read 
before the value is materialized by instruction retirement.

> I don't think that T2 can read non-null and then later read null given
> the code we are discussing.

Correct - program order would be violated.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

RE: RV-Predict bugs

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
> Subject: Re: RV-Predict bugs

> I discovered that within a synchronized block, the JIT is allowed to re-order
> statements if it determines it is safe to do so -- and that statements that 
> occur before the memory barrier must not be interleaved with statements 
> inside 
> the block, and likewise, nothing after the block can be moved "inside" that 
> block.

Correct, mostly; the exceptions are that operations that can be proven to not 
have any dependencies on those within the block could theoretically be moved to 
inside or prior to the block (but compilers generally won't bother to do that 
when there's a memory barrier).

> But it seems reasonable that the JIT would be allowed to perform some
> otherwise "conditional" code execution *before* the condition is
> actually evaluated, as long as that code doesn't have any side-effects
> (such as assignment of the return value of, say, hashCode() or
> StringManager.getString()).

Yes, speculative executions are allowed, as long as program order isn't 
violated.

> I'm sure the rules for "side-effects" include calling methods not yet proven 
> to 
> have any side-effects which might be a giant rathole that nobody has decided 
> to
> jump into, and therefore method calls are always considered "side effects" 
> just 
> to keep things safe and simple.

Nope.  I spend much of my time inside LLVM these days, and a significant chunk 
of optimizations can be enabled when functions are known not to have side 
effects.  There's a lot of effort put into annotating function declarations to 
let the compiler know that they're safe.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

Re: RV-Predict bugs

[Yilong Li]

On Tue, Sep 15, 2015 at 12:06 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:

> > From: Yilong Li [mailto:yilong...@runtimeverification.com]
> > Subject: Re: RV-Predict bugs
>
> > > True, but as Mark previously pointed out, no one cares.  All that
> happens
> > > in that case is the object is redundantly created and then garbage
> > > collected later; no damage.
>
> > No, it's not right. It's possible (although very unlikely) that this
> method
> > could return null and results in a null pointer exception later.
>
> Again, that cannot happen; see below.
>
> > Intra-thread semantics says that event 3 (the first read of the field
> > hashCode) happens before event 4 (the second read of field hashCode) but
> it
> > has no effect on the value event 4 can see (because event 3 is also a
> read
> > rather than a write).
>
> You're mixing up inter- and intra-thread semantics and completely ignoring
> the write to hashCode when the initially observed value is zero.
> Intra-thread semantics require that operations occur in program order, so
> the initial zero (or null) check results in a non-zero (or non-null) write
> to the field of interest; control flow cannot be ignored here.  If your
> supposition were correct, a compiler (or CPU) would be free to migrate
> actions dependent on a conditional block to a spot prior to that
> conditional block - clearly that is nonsense.


Nope, I know what I am doing. Let's first see what the expert says. Please
check out the last section in this article (
http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.html)
which starts with "let's break the code". Here, we are talking about T2 in
the above example. The second read of the field hashCode is not
control-flow-dependent on the first read (the zero-check). Again,
intra-thread semantics introduces HB order between the event 3 and event 4.
But it doesn't ensure that event 4 must see the same value as event 3.

Yilong


>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: RV-Predict bugs

[Mark Thomas]

On 15/09/2015 20:42, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org] 
>> Subject: Re: RV-Predict bugs
> 
>> Putting it into my own words to check my understanding:
> 
>> - The two reads in T2 may be re-ordered because, in T2, there is nothing
>>   that requires a happens-before relationship between the two reads
> 
> Depends on what was really meant by the ??? notation.  If it were another 
> reference to st_200, then the example ignores the potential write to st_200.
> 
>> - If T2 was executing in isolation the order of the reads wouldn't
>>   matter
> 
> Correct, assuming there is no write in T2's control flow.
> 
>> - However, T1 is writing.
> 
>> So if the writes
> 
> I'll assume you meant "reads" there.

I'd did. Thanks.

>> in T2 are re-ordered and the write from T1 takes place between them the T2 
>> read for the line 'st_200 == null' could return a non-null value for st_200 
>> (the value after the write from T1) while the read for the line 'return 
>> st_200;' could return null (the value from before the write in T1).
> 
> No - that would violate program order (intra-thread semantics).  The compiler 
> cannot legally move the read for "return st_200" to a point before the 
> potential write to st_200.  The CPU can speculatively read for the return 
> value, but must discard such speculation if a write were to occur (or use 
> store forwarding to update the read).

Thanks for sticking with me on this. I'm finding it hugely helpful. I
think I need a few more references to make things clearer so I'm going
to restate the problem.

st_200 is non-volatile

L1 if (st_200 == null ) {
L2st_200 = sm.getString("sc.200");
L3 }
L4 return st_200;

Ln=Line n
Tx=Thread x
Rn=Read at line n
Wn=Write at line n

So T2 has two reads, T2R1 and T2R4.
Depending on the value read for T2R1 there may be a write at T2W2.
If there is a write there is a happens before relationship between T2R1
and T2R4.

Consider the following sequence

T2R4 (out of order read returns null)
T1R1 (returns null)
T1W2 (writes non-null value)
T1R4 (reads new non-null value)
T2R1 (reads new non-null value)

Because T2R1 reads a non-null value there is no write in T2.
Therefore there is no happens-before relationship between T2R1 and T2R4
because there is no intervening write in that thread (the write happens
in T1).
Therefore the re-ordering is allowed to happen.
And we get the unexpected result.

Or

The write at T1W2 is sufficient to enforce the happens before
relationship between T2R1 and T2R4. In which case what is the point of
volatile? What do I gain by using it?

A still slightly confused,

Mark


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

Re: svn commit: r1703151 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

[Felix Schumacher]

Am 15. September 2015 21:47:57 MESZ, schrieb Mark Thomas :
>On 15/09/2015 18:41, Felix Schumacher wrote:
>> Hi Mark,
>> 
>> why didn't you remove the synchronization when you converted the code
>to
>> ConcurrentLinkedDeque?
>
>No idea. Focusing on one thing and missing the obvious I suspect.
>
>> The old code had a concurrency problem, since events.size() was
>checked
>> outside of the synchronize block. I think this is not a problem
>anymore,
>> but I don't understand the call to events.clear() afterwards the
>> while-loop in events(). We think we have guarded the queue and
>removed
>> all entries by calling pollFirst repeatedly, so why clear it
>afterwards?
>
>Don't know. I'll take another look and clean it up some more.

While you are looking at the code. The api docs say that queue.size() is quite 
expensive. My guess is, that queue.isEmpty() is quite cheap. 

Best regards, 
Felix
>
>Mark
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: dev-h...@tomcat.apache.org


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

svn commit: r1703287 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

[markt]

Author: markt
Date: Tue Sep 15 20:24:49 2015
New Revision: 1703287

URL: http://svn.apache.org/r1703287
Log:
Follow-up to r1703151
More clean-up and remove an unnecessary clear() that could cause problems.

Modified:
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

Modified: 
tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java
URL: 
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java?rev=1703287&r1=1703286&r2=1703287&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
(original)
+++ tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java 
Tue Sep 15 20:24:49 2015
@@ -145,9 +145,7 @@ public class NioReceiver extends Receive
 public void addEvent(Runnable event) {
 Selector selector = this.selector.get();
 if (selector != null) {
-synchronized (events) {
-events.add(event);
-}
+events.add(event);
 if (log.isTraceEnabled()) {
 log.trace("Adding event to selector:" + event);
 }
@@ -158,22 +156,19 @@ public class NioReceiver extends Receive
 }
 
 public void events() {
-if (events.size() == 0) {
+if (events.isEmpty()) {
 return;
 }
-synchronized (events) {
-Runnable r = null;
-while ((r = events.pollFirst()) != null ) {
-try {
-if (log.isTraceEnabled()) {
-log.trace("Processing event in selector:" + r);
-}
-r.run();
-} catch (Exception x) {
-log.error("", x);
+Runnable r = null;
+while ((r = events.pollFirst()) != null ) {
+try {
+if (log.isTraceEnabled()) {
+log.trace("Processing event in selector:" + r);
 }
+r.run();
+} catch (Exception x) {
+log.error("", x);
 }
-events.clear();
 }
 }
 



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

RE: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Caldarale, Charles R]

> From: Mark Thomas [mailto:ma...@apache.org] 
> Subject: Re: svn commit: r1703194 - 
> /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

> What prevents the concurrency is that there is only ever one background
> thread. The only was I see this happening is:
> - T1 runs and expires all the current sessions.
> - The container unregisters itself from background processing since it
>   has no sessions
> - It was the only thing registered for background processing so the
>   T1 is terminated by the BackgroundProcessManager
> - A new WeBSoket session is opened
> - The container registers itself with the BackgroundProcessManager
> - A new background processing thread T2 is started
> - T2 runs

> RV-Predict indicated that there was a race. Was this a false positive?

Sounds like a false positive to me.  There are numerous implicit 
synchronizations in the above sequence, so the volatile is not particularly 
useful (but it's not terribly expensive either).

> I was looking at keyset

> "they are guaranteed to traverse elements as they existed upon
> construction exactly once, and may (but are not guaranteed to) reflect
> any modifications subsequent to construction."

Ok, finally found the above under 
java/util/concurrent/package-summary.html#Weakly, so that seems to be ok.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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

svn commit: r1703288 - in /tomcat/tc8.0.x/trunk: ./ java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

[markt]

Author: markt
Date: Tue Sep 15 20:25:52 2015
New Revision: 1703288

URL: http://svn.apache.org/r1703288
Log:
Follow-up to r1703153

Modified:
tomcat/tc8.0.x/trunk/   (props changed)

tomcat/tc8.0.x/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

Propchange: tomcat/tc8.0.x/trunk/
--
--- svn:mergeinfo (original)
+++ svn:mergeinfo Tue Sep 15 20:25:52 2015
@@ -1 +1 @@
-/tomcat/trunk:1636524,1637156,1637176,1637188,1637331,1637684,1637695,1638720-1638725,1639653,1640010,1640083-1640084,1640088,1640275,1640322,1640347,1640361,1640365,1640403,1640410,1640652,1640655-1640658,1640688,1640700-1640883,1640903,1640976,1640978,1641000,1641026,1641038-1641039,1641051-1641052,1641058,1641064,1641300,1641369,1641374,1641380,1641486,1641634,1641656-1641692,1641704,1641707-1641718,1641720-1641722,1641735,1641981,1642233,1642280,1642554,1642564,1642595,1642606,1642668,1642679,1642697,1642699,1642766,1643002,1643045,1643054-1643055,1643066,1643121,1643128,1643206,1643209-1643210,1643216,1643249,1643270,1643283,1643309-1643310,1643323,1643365-1643366,1643370-1643371,1643465,1643474,1643536,1643570,1643634,1643649,1643651,1643654,1643675,1643731,1643733-1643734,1643761,1643766,1643814,1643937,1643963,1644017,1644169,1644201-1644203,1644321,1644323,1644516,1644523,1644529,1644535,1644730,1644768,1644784-1644785,1644790,1644793,1644815,1644884,1644886,1644890,1644892
 
,1644910,1644924,1644929-1644930,1644935,1644989,1645011,1645247,1645355,1645357-1645358,1645455,1645465,1645469,1645471,1645473,1645475,1645486-1645488,1645626,1645641,1645685,1645743,1645763,1645951-1645953,1645955,1645993,1646098-1646106,1646178,1646220,1646302,1646304,1646420,1646470-1646471,1646476,1646559,1646717-1646723,1646773,1647026,1647042,1647530,1647655,1648304,1648815,1648907,1650081,1650365,1651116,1651120,1651280,1651470,1652938,1652970,1653041,1653471,1653550,1653574,1653797,1653815-1653816,1653819,1653840,1653857,1653888,1653972,1654013,1654030,1654050,1654123,1654148,1654159,1654513,1654515,1654517,1654522,1654524,1654725,1654735,1654766,1654785,1654851-1654852,1654978,1655122-1655124,1655126-1655127,1655129-1655130,1655132-1655133,1655312,1655438,1655441,1655454,168,1656087,1656299,1656319,1656331,1656345,1656350,1656590,1656648-1656650,1656657,1657041,1657054,1657374,1657492,1657510,1657565,1657580,1657584,1657586,1657589,1657592,1657607,1657609,1657682,1657
 
907,1658207,1658734,1658781,1658790,1658799,1658802,1658804,1658833,1658840,1658966,1659043,1659053,1659059,1659188-1659189,1659216,1659263,1659293,1659304,1659306-1659307,1659382,1659384,1659428,1659471,1659486,1659505,1659516,1659521,1659524,1659559,1659562,1659803,1659806,1659814,1659833,1659862,1659905,1659919,1659948,1659967,1659983-1659984,1660060,1660074,1660077,1660133,1660168,1660331-1660332,1660353,1660358,1660924,1661386,1661867,1661972,1661990,1662200,1662308-1662309,1662548,1662614,1662736,1662985,1662988-1662989,1663264,1663277,1663298,1663534,1663562,1663676,1663715,1663754,1663768,1663772,1663781,1663893,1663995,1664143,1664163,1664174,1664301,1664317,1664347,1664657,1664659,1664710,1664863-1664864,1664866,1665085,1665292,1665559,1665653,1665661,1665672,1665694,1665697,1665736,1665779,1665976-1665977,1665980-1665981,1665985-1665986,1665989,1665998,1666004,1666008,1666013,1666017,1666024,1666116,1666386-1666387,1666494,1666496,1666552,1666569,1666579,137,149,1
 
666757,1666966,1666972,1666985,1666995,1666997,1667292,1667402,1667406,1667546,1667615,1667630,1667636,1667688,1667764,1667871,1668026,1668135,1668193,1668593,1668596,1668630,1668639,1668843,1669353,1669370,1669451,1669800,1669838,1669876,1669882,1670394,1670433,1670591,1670598-1670600,1670610,1670631,1670719,1670724,1670726,1670730,1670940,1671112,1672272,1672284,1673754,1674294,1675461,1675486,1675594,1675830,1676231,1676250-1676251,1676364,1676381,1676393,1676479,1676525,1676552,1676615,1676630,1676634,1676721,1676926,1676943,1677140,1677802,1678011,1678162,1678174,1678339,1678426-1678427,1678694,1678701,1679534,1679708,1679710,1679716,1680034,1680246,1681056,1681123,1681138,1681280,1681283,1681286,1681450,1681697,1681701,1681729,1681770,1681779,1681793,1681807,1681837-1681838,1681854,1681862,1681958,1682028,1682033,1682311,1682315,1682317,1682320,1682324,1682330,1682842,1684172,1684366,1684383,1684526-1684527,1684549-1684550,1685556,1685591,1685739,1685744,1685772,1685816,168582
 
6,1685891,1687242,1687261,1687268,1687340,1688563,1688841,1688878,165,1688896,1688901,1689345-1689346,1689357,1689656,1689675-1689677,1689679,1689687,1689825,1689856,1689918,1690011,1690021,1690054,1690080,1690209,1691134,1691487,1691813,1692744-1692747,1692849,1693088,1693105,1693429,1693461,1694058,1694111,1694290,1694501,1694548,1694658,1694660,1694788,1694872,1694878,1695006,1695354,1695371,1695459,1695582,1695706,1695778,1696199,1696272,1696280,1696366-1696368,1696378,1696390,1696392,1696467,1700607,1700870,170

Re: svn commit: r1703151 - /tomcat/trunk/java/org/apache/catalina/tribes/transport/nio/NioReceiver.java

[Mark Thomas]

On 15/09/2015 21:18, Felix Schumacher wrote:
> 
> 
> Am 15. September 2015 21:47:57 MESZ, schrieb Mark Thomas :
>> On 15/09/2015 18:41, Felix Schumacher wrote:
>>> Hi Mark,
>>>
>>> why didn't you remove the synchronization when you converted the code
>> to
>>> ConcurrentLinkedDeque?
>>
>> No idea. Focusing on one thing and missing the obvious I suspect.
>>
>>> The old code had a concurrency problem, since events.size() was
>> checked
>>> outside of the synchronize block. I think this is not a problem
>> anymore,
>>> but I don't understand the call to events.clear() afterwards the
>>> while-loop in events(). We think we have guarded the queue and
>> removed
>>> all entries by calling pollFirst repeatedly, so why clear it
>> afterwards?
>>
>> Don't know. I'll take another look and clean it up some more.
> 
> While you are looking at the code. The api docs say that queue.size() is 
> quite expensive. My guess is, that queue.isEmpty() is quite cheap.

All fixed. (I think.)

Thanks for the review.

Mark


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

Re: RV-Predict bugs

[Yilong Li]

On Tue, Sep 15, 2015 at 12:29 PM, Mark Thomas  wrote:

> On 15/09/2015 17:59, Yilong Li wrote:
> > On Tue, Sep 15, 2015 at 7:19 AM, Mark Thomas  wrote:
>
> >> Long experience has lead us to be sceptical of bugs reported by
> >> automated tools. When looking at such bugs and we can't see what the
> >> problem is and the person raising the bug can't provide a clear
> >> explanation - and continues not to provide a clear explanation when
> >> asked for one several times - then that is the point where we start to
> >> think the problem is with the tool.
> >>
> >
> > Sorry, I should not assume that the concepts such as happens-before order
> > and memory model are well understood. Let's talk about how this is
> allowed
> > to happen under JMM. Consider the this example again:
> >
> > if (st_200 == null ) {
> > st_200 = sm.getString("sc.200");
> > }
> > return st_200;
> >
> > The following is a valid execution trace consists of 5 events:
> > T1   T2
> > 1   READ  null
> > 2   WRITE s
> > 3 READ s
> > 4 READ ???
> > 5   READ  s
> >
> > , where s is the result of sm.getString("sc.200").
> >
> > T1 sees null in field st_200, initializes it, and return the initialized
> > value, while T2 sees a non-null value in st_200 and skips the
> > initialization. The question is what value T2 can read and then return in
> > event 4. This is addressed in JLS $17.4.5 Happens-before Order (
> > https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.5
> ):
> >
> > We say that a read *r* of a variable *v* is allowed to observe a write
> *w*
> > to *v* if, in the *happens-before* partial order of the execution trace:
> >
> >-
> >
> >*r* is not ordered before *w* (i.e., it is not the case that *hb(r,
> w)*),
> >and
> >-
> >
> >there is no intervening write *w*' to *v* (i.e. no write *w*' to *v*
> such
> >that *hb(w, w')* and *hb(w', r)*).
> >
> > Informally, a read *r* is allowed to see the result of a write *w* if
> there
> > is no *happens-before* ordering to prevent that read.
> >
> > The question boils down to: does the write in event 2 prevent event 4
> from
> > reading the initial null value of st_200? No, because there is no
> > happens-before order involved here. So what kind of constructs introduce
> > happens-before order? This question is also addressed in the same section
> > of JLS:
> >
> > It follows from the above definitions that:
> >
> >-
> >
> >An unlock on a monitor *happens-before* every subsequent lock on that
> >monitor.
> >-
> >
> >A write to a volatile field (§8.3.1.4
> ><
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.3.1.4>
> >) *happens-before* every subsequent read of that field.
> >-
> >
> >A call to start() on a thread *happens-before* any actions in the
> >started thread.
> >-
> >
> >All actions in a thread *happen-before* any other thread successfully
> >returns from a join() on that thread.
> >-
> >
> >The default initialization of any object *happens-before* any other
> >actions (other than default-writes) of a program.
>
> Thank you. That helps fill in a few gaps. Putting it into my own words
> to check my understanding:
>
> - The two reads in T2 may be re-ordered because, in T2, there is nothing
>   that requires a happens-before relationship between the two reads
>
> - If T2 was executing in isolation the order of the reads wouldn't
>   matter
>
> - However, T1 is writing.
>
> So if the writes in T2 are re-ordered and the write from T1 takes place
> between them the T2 read for the line 'st_200 == null' could return a
> non-null value for st_200 (the value after the write from T1) while the
> read for the line 'return st_200;' could return null (the value from
> before the write in T1).
>
> Is my understanding correct?
>

Not really. I have been trying to avoid getting into the discussion about
the low-level stuffs such as instruction reordering and caching. Let's stay
on the abstraction level of JMM. When reasoning on the level of JMM, one
should not care about reordering or speculative read. The happens-before
order is the only thing that matters. I know it could be confusing because
of the name, but happens-before order is orthogonal to whether two
operations can be reordered. The latter is the low-level detail that JMM
abstracts away. The first read in T2 does happen-before the second read
because of the intra-thread semantics (sorry, I forgot to include
intra-thread semantics when I pasted the constructs that introduce HB
order). However, in order to reason about what value the second read can
see, one has to stick to the two rules specified by JMM I quoted in my
previous message. In short, when reasoning with JMM, just assume the
instructions are executed in the same order as in the source code and start
reasoning about what value a read can see from there.

Yilong


>

Re: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Mark Thomas]

On 15/09/2015 21:24, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org] 
>> Subject: Re: svn commit: r1703194 - 
>> /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
> 
>> What prevents the concurrency is that there is only ever one background
>> thread. The only was I see this happening is:
>> - T1 runs and expires all the current sessions.
>> - The container unregisters itself from background processing since it
>>   has no sessions
>> - It was the only thing registered for background processing so the
>>   T1 is terminated by the BackgroundProcessManager
>> - A new WeBSoket session is opened
>> - The container registers itself with the BackgroundProcessManager
>> - A new background processing thread T2 is started
>> - T2 runs
> 
>> RV-Predict indicated that there was a race. Was this a false positive?
> 
> Sounds like a false positive to me.  There are numerous implicit 
> synchronizations in the above sequence, so the volatile is not particularly 
> useful (but it's not terribly expensive either).

Thanks. I'll revert that fix and resolve it as invalid.

Mark


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

[Bug 58404] Duplicate property definitions compile.[source|target] in build.properties.default and build.xml

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58404

--- Comment #2 from Sebb  ---
(In reply to Christopher Schultz from comment #1)
> This may not be a bug: ant scripts often provide sane defaults in case the
> properties files do not specify a value: 

See Bug 58083 - the same issue was fixed in Tomcat itself.

> it's possible to remove
> compile.source for example from build.properties.default and end up
> confusing the compiler.

build.properties.default is not supposed to be changed.

> Note that ant does not allow property values to be changed once they have
> been set, so the value from build.properties.default will override the
> default hard-coded in build.xml.

This is partly why it's a bad idea; the user may change the value in build.xml
and wonder why the change has no effect.

But the main issue is that it's not a good idea to have multiple definitions of
the same data. At least one definition is likely to get out of date. viz JUnit.

Either define the values in the properties file or in build.xml; don't define
them in both. But I think the properties file is better for these properties;
it's easier to read and maintain.

-- 
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 58081] Incorrect Java version in README

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58081

--- Comment #3 from Sebb  ---
(In reply to Christopher Schultz from comment #2)
> I think the Java source in there is now primarily there for historical
> reasons. Does anyone actually build the Java code from the tcnative project?

In case anyone does, it's a trivial fix to make.

-- 
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

Re: svn commit: r1703194 - /tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java

[Rémy Maucherat]

2015-09-15 22:28 GMT+02:00 Mark Thomas :

> > Sounds like a false positive to me.  There are numerous implicit
> synchronizations in the above sequence, so the volatile is not particularly
> useful (but it's not terribly expensive either).
>
> Thanks. I'll revert that fix and resolve it as invalid.
>
> OTOH since you're in that section, the TCK prefers if the background check
for session expiration is run once per second. How epensive is it ? It
would make that algorithm a lot simpler.

Rémy