At this point I tend to agree with Ylong and Jeremy. I’m very far from being
an expert but I thought 14.2 meant that the result of execution of a single
thread had to be the same as if it executed the given instructions in the order
supplied. I didn’t think it meant it had to execute those par
https://bz.apache.org/bugzilla/show_bug.cgi?id=58416
ko_nakam...@sdcns.co.jp changed:
What|Removed |Added
CC||ko_nakam...@sdcns.co.jp
--
Y
https://bz.apache.org/bugzilla/show_bug.cgi?id=58416
Bug ID: 58416
Summary: Possibly wrong check condition in catalina.sh
Product: Tomcat 7
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: minor
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #8 from Steve Davids ---
PrintWriter doesn't say anything specifically about thread safety but the
Writer implies it with the constructor saying:
http://docs.oracle.com/javase/8/docs/api/java/io/Writer.html#Writer--
> Creates a new
Am 15. September 2015 23:10:30 MESZ, schrieb ma...@apache.org:
>Author: markt
>Date: Tue Sep 15 21:10:30 2015
>New Revision: 1703290
>
>URL: http://svn.apache.org/r1703290
>Log:
>Follow-up to r1703177.
>Ensure that members never contains an intermediate result of the
>sorting process.
>
>Modified
On Tue, Sep 15, 2015 at 6:29 PM, Caldarale, Charles R <
chuck.caldar...@unisys.com> wrote:
> > From: Yilong Li [mailto:yilong...@runtimeverification.com]
> > Subject: Re: RV-Predict bugs
>
> > So you are saying that the author of JMM misunderstands his own work?
>
> No, I'm saying that he's only l
Your argument seems to assume that reordering is the only code
transformation that can be done by compiler or hardware. I don't agree that
you call this transformation a red herring. It might not be practical but
it's certainly valid. Does it violate the intra-thread semantics you
mentioned in JLS
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> My expectation is that once T2 has seen the updated value (originated
> from another thread) all subsequent reads in T2 of the same field are
> going to see the same value rather than some of those reads seeing an
> ol
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> I understand that the JMM allows this behaviour. I don't understand how
> this could happen in a JVM implementation.
I don't believe it can, on any supported hardware.
> If T2R1 has read a non-null value how could a
> From: David Jencks [mailto:david_jen...@yahoo.com.INVALID]
> Subject: Re: RV-Predict bugs
> I have been having a hard time believing the reordering claims, but finally I
> went to Jeremy's
> blog post. To recap, he says
> if (hash == 0) {
> int h = //compute hash
> hash = h;
> }
> retu
> From: Yilong Li [mailto:yilong...@runtimeverification.com]
> Subject: Re: RV-Predict bugs
> So you are saying that the author of JMM misunderstands his own work?
No, I'm saying that he's only looking at things from the point of view of 17.4,
and ignoring section 14.2 of the JLS. (BTW, prior
I have been having a hard time believing the reordering claims, but finally I
went to Jeremy’s blog post. To recap, he says
if (hash == 0) {
int h = //compute hash
hash = h;
}
return hash;
can be reordered to
r1 = hash;
if (hash == 0) {
r1 = hash = // calculate hash
}
return r1;
Obviou
The Buildbot has detected a new failure on builder tomcat-8-trunk while
building ASF Buildbot. Full details are available at:
http://ci.apache.org/builders/tomcat-8-trunk/builds/127
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: silvanus_ubuntu
Build Reason: The AnyBranchSch
On Tue, Sep 15, 2015 at 3:09 PM, Mark Thomas wrote:
> On 15/09/2015 22:55, Yilong Li wrote:
>
> > Fine. Let's do your example:
> > 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)
On 15/09/2015 23:09, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Subject: Re: RV-Predict bugs
>
>> To make sure I understand this it is the possibility of the write T2W2
>> that is sufficient to ensure T2R1 and T2R4 are not re-ordered not the
>> possibility of a
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #7 from Mark Thomas ---
I was all for closing it as INVALID as well then I went I dug through the
Javadoc. Is there anything you can recall in the Servlet spec, javadoc or the
EG discussions that points to the PrintWriter being thre
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> To make sure I understand this it is the possibility of the write T2W2
> that is sufficient to ensure T2R1 and T2R4 are not re-ordered not the
> possibility of a write in some other thread?
Section 14.2 requires that
On 15/09/2015 22:55, Yilong Li wrote:
> Fine. Let's do your example:
> 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)
>
> First of all, when reasoning with JMM, you should not move T2R4
On 15/09/2015 22:34, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Subject: Re: RV-Predict bugs
>
>> 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=R
https://bz.apache.org/bugzilla/show_bug.cgi?id=58414
Evgeny Mironenko changed:
What|Removed |Added
Summary|It is not possible to |Can not transfer empty
https://bz.apache.org/bugzilla/show_bug.cgi?id=58404
Christopher Schultz changed:
What|Removed |Added
Status|NEEDINFO|NEW
--- Comment #3 from Christop
On Tue, Sep 15, 2015 at 2:33 PM, Mark Thomas wrote:
> On 15/09/2015 21:51, Yilong Li wrote:
> > On Tue, Sep 15, 2015 at 1:09 PM, Mark Thomas wrote:
> >
> >> On 15/09/2015 20:42, Caldarale, Charles R wrote:
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> >
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #6 from Remy Maucherat ---
Really ? Those (legacy) Servlet objects have never been synced.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58414
Bug ID: 58414
Summary: It is not possible to transfer empty string through
Web Socket
Product: Tomcat 8
Version: 8.0.26
Hardware: PC
Status: NEW
Sev
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
Mark Thomas changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
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/126
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: silvanus_ubuntu
Build Reason: The AnyBranch
> From: Mark Thomas [mailto:ma...@apache.org]
> Subject: Re: RV-Predict bugs
> 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 a
Sorry, I am confused. So you are saying that the author of JMM
misunderstands his own work? Well, I highly doubt that. I don't understand
why you interpret JMM in a way that excludes intra-thread semantics. How is
it possible for JMM to be of any use if it does not take into account the
intra-threa
On 15/09/2015 21:51, Yilong Li wrote:
> On Tue, Sep 15, 2015 at 1:09 PM, Mark Thomas wrote:
>
>> 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 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/287
Buildbot URL: http://ci.apache.org/
Buildslave for this Build: silvanus_ubuntu
Build Reason: The AnyBranchSch
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
--- Comment #4 from Steve Davids ---
I have a distributed system that needs to collect data on each data node and
stream it back to the client in a timely manner, so I go ahead and open up
multiple concurrent InputStreams from each data node an
https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
--- Comment #3 from Yilong Li ---
Interesting, I have my reservations on this. I will find some time to
investigate it further. Thanks!
--
You are receiving this mail because:
You are the assignee for the bug.
---
Author: markt
Date: Tue Sep 15 21:19:00 2015
New Revision: 1703294
URL: http://svn.apache.org/r1703294
Log:
Revert r1703194. Bug report was a false positive.
Modified:
tomcat/trunk/java/org/apache/tomcat/websocket/WsWebSocketContainer.java
Modified:
tomcat/trunk/java/org/apache/tomcat/webso
https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
Mark Thomas changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #2 from Mark Thomas
Author: markt
Date: Tue Sep 15 21:11:52 2015
New Revision: 1703291
URL: http://svn.apache.org/r1703291
Log:
Follow-up to r1703177.
Ensure that members never contains an intermediate result of the sorting
process.
Modified:
tomcat/tc8.0.x/trunk/ (props changed)
tomcat/tc8.0.x/trunk/jav
Author: markt
Date: Tue Sep 15 21:10:30 2015
New Revision: 1703290
URL: http://svn.apache.org/r1703290
Log:
Follow-up to r1703177.
Ensure that members never contains an intermediate result of the sorting
process.
Modified:
tomcat/trunk/java/org/apache/catalina/tribes/membership/Membership.ja
On 15/09/2015 20:38, Mark Thomas wrote:
> 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: ht
> From: Yilong Li [mailto:yilong...@runtimeverification.com]
> Subject: Re: RV-Predict bugs
> 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)
> whic
On Tue, Sep 15, 2015 at 1:09 PM, Mark Thomas wrote:
> 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-order
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.
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 anyo
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
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
>> threa
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
>
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.
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.
> 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
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
M
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.
>
>>
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-
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
> 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 no
> 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 read
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
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 checke
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 t
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 i
> 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
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:
>
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 singl
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.
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
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
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.
Internal
> 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 for
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
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 garb
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 memb
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.jav
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 som
> 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. I
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 i
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
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
https://bz.apache.org/bugzilla/show_bug.cgi?id=58411
Remy Maucherat changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
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
Statu
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
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
> 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 t
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.x
> 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
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
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.xm
https://bz.apache.org/bugzilla/show_bug.cgi?id=58404
Christopher Schultz changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Chr
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 th
> 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
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.
> 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
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
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 m
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 t
> 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. I
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,
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 AnyBranc
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 AnyBranch
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.
---
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 th
https://bz.apache.org/bugzilla/show_bug.cgi?id=58385
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58384
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
1 - 100 of 139 matches
Mail list logo
