DO NOT REPLY [Bug 49778] New: Inconsistent synchronization in SimplePool.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
Summary: Inconsistent synchronization in SimplePool.java
Product: Tomcat 6
Version: 6.0.18
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: fsl...@gmail.com
In class org.apache.tomcat.util.collections.SimplePool, current is a mutable
field. In method put/get, current field is updated with a lock held. But in
method getCount(), the access to current field is not protected by a lock.
In current Java memory model, the up-to-date current field value is not
guaranteed to be seen in the absence of synchronization. So getCount() method
can return a stale or inconsistent value, which results in undesired behavior.
Proposed solution:
public int getCount() {
int ret = 0;
synchronized (lock) {
ret = current+1;
}
return ret;
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
DO NOT REPLY [Bug 49779] New: 501 Method not implemented with successive POST requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=49779 Summary: 501 Method not implemented with successive POST requests Product: Tomcat 7 Version: 7.0.0 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: hanswae...@gmail.com Created an attachment (id=25911) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25911) client wire/context log, client code, webapp code An unexpected HTTP 501 occurs if using HttpComponents with successive POST requests against a simple Tomcat 7 servlet (Form-based POST Authentication is enabled). After a sucessfull authentication, the client requests the same protected resource a few times in a row, but the second request always returns a "501 Method not implemented" status. All other requests succeed. The following communication takes place: 1. Client requests a protected resource; Tomcat returns the login page (HTTP200) 2. Client provides the user credentials and calls the login resource; Tomcat returns a redirect (HTTP302) 3. Client sets the location from the redirect for the next request(identical to URI from #1) and requests it; Tomcat returns the page (HTTP200) 4. Client requests the same resource again; Tomcat returns a HTTP501 - Method not implemented 5. Client requests the same resource again; Tomcat returns the page (HTTP200) 6. Client requests the same resource again; Tomcat returns the page (HTTP200) 7. Client requests the same resource again; Tomcat returns the page (HTTP200) The access log message regarding the 501 says: '"testName=testValuePOST /test/secure/ HTTP/1.1" 501 1278', which may indicate that the entity data and the HTTP-method name somehow got mixed up!? Strangely the HTTP501 does not appear in case of a JSP for the requested resource, only if facing a form-based POST authentication Servlet. The servlet does only implement post and get(which calls the doPost) and returns just a string. The client code should be fine since I already posted this issue on the HTTPComponents mailing list and the data sent over the wire seems to be right. I attached the source/bin of the testclient and webapp and also the wire/context log of the client. How can I provide further helpfull information? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49779] 501 Method not implemented with successive POST requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=49779 --- Comment #1 from hanswae...@gmail.com 2010-08-19 05:53:00 EDT --- also tested against Tomcat v6.0.29 with the same result and against Tomcat v5.5 (I think) which returns the correct return code HTTP 200, but threw internal exceptions. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49780] New: Sessions getting mixed up
https://issues.apache.org/bugzilla/show_bug.cgi?id=49780
Summary: Sessions getting mixed up
Product: Tomcat 6
Version: 6.0.26
Platform: Other
OS/Version: Linux
Status: NEW
Severity: critical
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: yawar.sa...@mcb.com.pk
I have developed a web application using jsp and servlets with oracle database.
The application is working great on windows. but the problem arises when we
deploy it on Linux, we get session issues in the application. The session
variables get mixed up and we can see previously logged user's profile page.
The menu options sometime show of previously logged users, sometimes currently
logged user's.
For example, session.getAttribute("role_id") sometime retrieves 0 and sometimes
1. depending on previous values.
please help!
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
DO NOT REPLY [Bug 49780] Sessions getting mixed up
https://issues.apache.org/bugzilla/show_bug.cgi?id=49780 Pid changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Pid 2010-08-19 06:16:54 EDT --- Bugzilla is not a support forum. Please ask this question on the Tomcat Users mailing list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49780] Sessions getting mixed up
https://issues.apache.org/bugzilla/show_bug.cgi?id=49780 Yawar Khan changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #2 from Yawar Khan 2010-08-19 06:21:08 EDT --- (In reply to comment #1) > Bugzilla is not a support forum. > Please ask this question on the Tomcat Users mailing list. I asked this question here to find out whether there is a bug in tomcat 6.0.26 session management or not? If the sourcecode is fine then there must be some problem in tomcat. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49779] 501 Method not implemented with successive POST requests
https://issues.apache.org/bugzilla/show_bug.cgi?id=49779 hanswae...@gmail.com changed: What|Removed |Added CC||hanswae...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49778] Inconsistent synchronization in SimplePool.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778
--- Comment #1 from Chuck Caldarale 2010-08-19
08:54:53 EDT ---
(In reply to comment #0)
> Proposed solution:
>
> public int getCount() {
> int ret = 0;
> synchronized (lock) {
> ret = current+1;
> }
> return ret;
> }
Such a change is utterly useless. Since the lock is dropped immediately after
retrieving the value, the value may change well before any decisions can be
made based on the value. This is completely independent of the JVM memory
model.
If you want to insure that getCount always retrieves the current value, the
field must be flagged as volatile - but that does nothing to prevent it
changing the moment after it has been referenced.
- Chuck
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
DO NOT REPLY [Bug 49785] New: Enabling TLS for JNDIRealm
https://issues.apache.org/bugzilla/show_bug.cgi?id=49785 Summary: Enabling TLS for JNDIRealm Product: Tomcat 7 Version: trunk Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: felix.schumac...@internetallee.de Created an attachment (id=25916) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=25916) InitialContextFactory which produces TLS enabled LdapContext instances To enable TLS for LDAP inside JNDIRealm one has to either patch JNDIRealm directly and introduce another state variable to hold TLS-state - and thus make introduction of pooling harder, or use a factory which produces TLS enabled DirContext instances. Such a factory is attached. It can be configured by specifying a contextFactory in JNDIRealm config:I think it would be a good idea to add a parameter startTLS to JNDIRealm, which would automatically use the above TLS-ContextFactory. If wanted, I could supply a patch. (the patch is against tomcat 6.0.x trunk, but I think it will apply fine to trunk too) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r987253 - in /tomcat/site/trunk: docs/download-70.html docs/index.html xdocs/download-70.xml xdocs/index.xml
Author: markt Date: Thu Aug 19 18:01:44 2010 New Revision: 987253 URL: http://svn.apache.org/viewvc?rev=987253&view=rev Log: Update for 7.0.2 beta Modified: tomcat/site/trunk/docs/download-70.html tomcat/site/trunk/docs/index.html tomcat/site/trunk/xdocs/download-70.xml tomcat/site/trunk/xdocs/index.xml Modified: tomcat/site/trunk/docs/download-70.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/download-70.html?rev=987253&r1=987252&r2=987253&view=diff == --- tomcat/site/trunk/docs/download-70.html (original) +++ tomcat/site/trunk/docs/download-70.html Thu Aug 19 18:01:44 2010 @@ -3,17 +3,17 @@ Apache Tomcat - Apache Tomcat 7 Downloads - - + + - - + + http://tomcat.apache.org/";> - + @@ -24,28 +24,28 @@ http://www.apache.org/";> -http://www.apache.org/images/asf-logo.gif"; /> +http://www.apache.org/images/asf-logo.gif"; align="right" alt="Apache Logo" border="0"/> -http://www.google.com/search";> - - - +http://www.google.com/search"; method="get"> + + + - + - + - + Apache Tomcat @@ -177,11 +177,11 @@ - - + + - + @@ -205,14 +205,14 @@ - + - + - + @@ -227,8 +227,8 @@ http://www.apache.org/dist/tomcat/tomcat-7/KEYS";>KEYS | -7.0.0 | -Browse | +7.0.2 | +Browse | http://archive.apache.org/dist/tomcat/tomcat-7";>Archives @@ -236,14 +236,14 @@ - + - + - + @@ -270,14 +270,14 @@ - + - + - + Mirrors @@ -293,8 +293,8 @@ encounter a problem with this mirror, please select another mirror. If all mirrors are failing, there are backup mirrors (at the end of the mirrors list) that should be - available.[if-any logo] - + available.[if-any logo] + [end] @@ -309,7 +309,7 @@ [for backup][backup] (backup)[end] [end] - + @@ -320,19 +320,19 @@ - + - + - - + + - -7.0.0 BETA + +7.0.2 BETA @@ -342,15 +342,15 @@ - Please see the - README + Please see the + README file for packaging information. It explains what every distribution contains. - + - + @@ -367,81 +367,81 @@ Core: -zip -(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0.zip.asc";>pgp, -http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0.zip.md5";>md5) +zip +(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2.zip.asc";>pgp, +http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2.zip.md5";>md5) -tar.gz -(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0.tar.gz.asc";>pgp, -http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0.tar.gz.md5";>md5) +tar.gz +(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2.tar.gz.asc";>pgp, +http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2.tar.gz.md5";>md5) -32-bit Windows zip -(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0-windows-x86.zip.asc";>pgp, -http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0-windows-x86.zip.md5";>md5) +32-bit Windows zip +(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2-windows-x86.zip.asc";>pgp, +http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2-windows-x86.zip.md5";>md5) -64-bit Windows zip -(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0-windows-x64.zip.asc";>pgp, -http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0-windows-x64.zip.md5";>md5) +64-bit Windows zip +(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2-windows-x64.zip.asc";>pgp, +http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2-windows-x64.zip.md5";>md5) -64-bit Itanium Windows zip -(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0-windows-i64.zip.asc";>pgp, -http://www.apache.org/dist/tomcat/tomcat-7/v7.0.0-beta/bin/apache-tomcat-7.0.0-windows-i64.zip.md5";>md5) +64-bit Itanium Windows zip +(http://www.apache.org/dist/tomcat/tomcat-7/v7.0.2-beta/bin/apache-tomcat-7.0.2-wind
Wiki edit rights
Hi folks, recently I've been asking stupid questions on users@ mailing list, now I would like to document my findings. So, can I please have edit rights - my nick is ``jmcg''. so long, i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Wiki edit rights
On 19.08.2010 22:34, Igor Galić wrote: Hi folks, recently I've been asking stupid questions on users@ mailing list, now I would like to document my findings. So, can I please have edit rights - my nick is ``jmcg''. As far as I know you select "Login" on the front page, click on "you can create one now" there, register yourself and then can do all editing. No special rights involved :) Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "JNDI_startTLs_HowTo" by jm cg
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change
notification.
The "JNDI_startTLs_HowTo" page has been changed by jmcg.
http://wiki.apache.org/tomcat/JNDI_startTLs_HowTo
--
New page:
In reference to:
http://www.mail-archive.com/us...@tomcat.apache.org/msg80660.html this Howto
describes the configuration of a JNDI Realm connecting to an LDAP directory
using StartTLS for connection establishment.
StartTLS is the method of negotiating a TLS connection. For LDAP it was first
time in RFC 2830, then refined in RFC 4513.
Tomcat does not support this out of the box. Using JNDI Realm's
`contextFactory` feature however, we can still achieve this:
{{{
ldap://primary.ldap.dir:389";
alternateURL="ldap://secondary.ldap.dir:389";
connectionName="uid=binddn" connectionPassword="password."
userBase="ou=people,dc=brainsware,dc=org" userSearch="uid={0}"
contextFactory="tc.startTLS.LdapTlsContextFactory />
}}}
Using the code provided by Felix Schumann in this post:
http://www.mail-archive.com/us...@tomcat.apache.org/msg80693.html
We have to compile it into a JAR and put in a place where Tomcat can find it:
`lib`. Then we simply reference its full name in `contextFactory`.
`LdapTlsContextFactory` will now do the negotiation initialization. Afterwards
the created object will be used for every authentication attempt.
== Further Steps ==
The code probably needs auditing. More testing. And definitely more tightening:
e.g.: When starting the negotiation the client (Tomcat +
`LdapTlsContextFactory`) sends an `SSLv2Hello`, which is anything but
desirable. This could be due to Sun’s poor defaults in their SSL
implementation, an oversight in the code, or because I’ve missed out a JVM
startup options.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "JNDI_HowTo" by jmcg
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "JNDI_HowTo" page has been changed by jmcg. http://wiki.apache.org/tomcat/JNDI_HowTo?action=diff&rev1=3&rev2=4 -- The port number (3268) connects to the global catalog. This is important because 389 might throw errors when getting referrals. (It sends a referral to ldap://company.com:389.) With this setting we don't have to change anything in /etc/hosts. + For a reference on starTLS, see Self:JNDI_startTLs_HowTo + [[CategoryFAQ|CategoryFAQ]] - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Wiki edit rights
- "Rainer Jung" wrote: > On 19.08.2010 22:34, Igor Galić wrote: > > > > Hi folks, > > > > recently I've been asking stupid questions on users@ mailing list, > > now I would like to document my findings. > > So, can I please have edit rights - my nick is ``jmcg''. > > As far as I know you select "Login" on the front page, click on "you > can > create one now" there, register yourself and then can do all editing. > No > special rights involved :) Fail. Thanks. Here's the Howto: http://wiki.apache.org/tomcat/JNDI_startTLs_HowTo > > Regards, > > Rainer i -- Igor Galić Tel: +43 (0) 664 886 22 883 Mail: i.ga...@brainsware.org URL: http://brainsware.org/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49785] Enabling TLS for JNDIRealm
https://issues.apache.org/bugzilla/show_bug.cgi?id=49785 --- Comment #1 from Rainer Jung 2010-08-19 18:11:37 EDT --- See also http://wiki.apache.org/tomcat/JNDI_startTLs_HowTo -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
New attachment added to page JNDI_startTLs_HowTo on Tomcat Wiki
Dear Wiki user, You have subscribed to a wiki page "JNDI_startTLs_HowTo" for change notification. An attachment has been added to that page by jmcg. Following detailed information is available: Attachment name: LdapTlsContextFactory.java Attachment size: 3752 Attachment link: http://wiki.apache.org/tomcat/JNDI_startTLs_HowTo?action=AttachFile&do=get&target=LdapTlsContextFactory.java Page link: http://wiki.apache.org/tomcat/JNDI_startTLs_HowTo - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of "JNDI_startTLs_HowTo" by jm cg
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification. The "JNDI_startTLs_HowTo" page has been changed by jmcg. http://wiki.apache.org/tomcat/JNDI_startTLs_HowTo?action=diff&rev1=1&rev2=2 -- contextFactory="tc.startTLS.LdapTlsContextFactory /> }}} - Using the code provided by Felix Schumann in this post: http://www.mail-archive.com/us...@tomcat.apache.org/msg80693.html + Using the code provided by Felix Schumann in this post: http://www.mail-archive.com/us...@tomcat.apache.org/msg80693.html - You can download it here: [[attachment:LdapTlsContextFactory.java]]. We have to compile it into a JAR and put in a place where Tomcat can find it: `lib`. Then we simply reference its full name in `contextFactory`. `LdapTlsContextFactory` will now do the negotiation initialization. Afterwards the created object will be used for every authentication attempt. == Further Steps == - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49778] Inconsistent synchronization in SimplePool.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778 --- Comment #2 from Sebb 2010-08-19 19:02:10 EDT --- (In reply to comment #1) > Such a change is utterly useless. Not true. The synchronisation block ensures that the value read by the thread is the current value. > Since the lock is dropped immediately after > retrieving the value, the value may change well before any decisions can be > made based on the value. This is completely independent of the JVM memory > model. True, but irrelevant here. > If you want to insure that getCount always retrieves the current value, the > field must be flagged as volatile Not strictly true. Volatile is _one_ way to ensure safe publication, but it is not the _only_ solution. Since the other accesses need to use synchronisation, it makes sense to use synchronisation here too. > - but that does nothing to prevent it > changing the moment after it has been referenced. Again true, but irrelevant. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49778] Inconsistent synchronization in SimplePool.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778 --- Comment #3 from Chuck Caldarale 2010-08-19 19:11:53 EDT --- (In reply to comment #2) > > > Since the lock is dropped immediately after retrieving > > the value, the value may change well before any decisions > > can be made based on the value. This is completely > > independent of the JVM memory model. > > True, but irrelevant here. No, it's pretty much the only relevant part. If the value can change after retrieval but before usage, you still don't have the current value. If decisions are to be made based on the value, the lock must be maintained across the retrieval and the decision. If no decisions are to be made on the value, then it doesn't matter if it's current, since it could change at any time. > > If you want to insure that getCount always retrieves the > > current value, the field must be flagged as volatile > > Not strictly true. Agreed; "must" was too strong. Flagging it as volatile is the least expensive way of insuring that the various compilers involved don't over-optimize the reference. Using a synchronization block is more expensive (although much cheaper in current JVMs than it used to be). > Since the other accesses need to use synchronisation, it > makes sense to use synchronisation here too. No, the other accesses are mutators; the reader of a simple value such as an int needs no synchronization - unless it's going to base some action on the value. > > - but that does nothing to prevent it > > changing the moment after it has been referenced. > > Again true, but irrelevant. Not at all irrelevant; the value retrieved is no longer current, which was your stated concern. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 49778] Inconsistent synchronization in SimplePool.java
https://issues.apache.org/bugzilla/show_bug.cgi?id=49778 --- Comment #4 from Sebb 2010-08-19 19:39:28 EDT --- (In reply to comment #3) > (In reply to comment #2) > > > > > Since the lock is dropped immediately after retrieving > > > the value, the value may change well before any decisions > > > can be made based on the value. This is completely > > > independent of the JVM memory model. > > > > True, but irrelevant here. > > No, it's pretty much the only relevant part. If the value can change after > retrieval but before usage, you still don't have the current value. If > decisions are to be made based on the value, the lock must be maintained > across > the retrieval and the decision. If no decisions are to be made on the value, > then it doesn't matter if it's current, since it could change at any time. What I meant was that it was irrelevant to the original bug report, which only pointed out that the value might be arbitrarily stale. > > > If you want to insure that getCount always retrieves the > > > current value, the field must be flagged as volatile > > > > Not strictly true. > > Agreed; "must" was too strong. Flagging it as volatile is the least expensive > way of insuring that the various compilers involved don't over-optimize the > reference. Using a synchronization block is more expensive (although much > cheaper in current JVMs than it used to be). Not necessarily the least expensive here. Adding volatile to the field affects all accesses, including the ones currently protected by synch. blocks. > > Since the other accesses need to use synchronisation, it > > makes sense to use synchronisation here too. > > No, the other accesses are mutators; the reader of a simple value such as an > int needs no synchronization - unless it's going to base some action on the > value. If it is not going to use the value, why read it in the first place? > > > - but that does nothing to prevent it > > > changing the moment after it has been referenced. > > > > Again true, but irrelevant. > > Not at all irrelevant; the value retrieved is no longer current, which was > your > stated concern. It was not my bug report... AIUI the original author was only concerned that the value might be stale. For example, if the count is to be displayed, it might not matter if the value is not 100% current, but it would matter if the value is arbitrarily stale. If the current exact value is needed, then of course the code needs to be part of the synch. block unless it is somehow known that the value cannot be changed by other threads at that point. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: r987387 - in /tomcat/site/trunk: docs/security-7.html xdocs/security-7.xml
Author: markt Date: Fri Aug 20 06:35:37 2010 New Revision: 987387 URL: http://svn.apache.org/viewvc?rev=987387&view=rev Log: Update for 7.0.2 release Modified: tomcat/site/trunk/docs/security-7.html tomcat/site/trunk/xdocs/security-7.xml Modified: tomcat/site/trunk/docs/security-7.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-7.html?rev=987387&r1=987386&r2=987387&view=diff == --- tomcat/site/trunk/docs/security-7.html (original) +++ tomcat/site/trunk/docs/security-7.html Fri Aug 20 06:35:37 2010 @@ -201,7 +201,7 @@ Apache Tomcat 7.x vulnerabilities -Fixed in subversion for Apache Tomcat 7.0.1 +Fixed in Apache Tomcat 7.0.2 Not a vulnerability in Tomcat @@ -258,11 +258,11 @@ - + - -Fixed in subversion for Apache Tomcat 7.0.1 + +Fixed in Apache Tomcat 7.0.2 @@ -272,11 +272,14 @@ - -Note: These issues will be fixed in 7.0.1 but that version has not - yet been released. + +Note: The issue below was fixed in Apache Tomcat 7.0.1 but the + release vote for the 7.0.1 release candidate did not pass. Therefore, + although users must download 7.0.2 to obtain a version that includes a + fix for this issue, version 7.0.2 is not included in the list of + affected versions. - + Important: Remote Denial Of Service and Information Disclosure Vulnerability Modified: tomcat/site/trunk/xdocs/security-7.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-7.xml?rev=987387&r1=987386&r2=987387&view=diff == --- tomcat/site/trunk/xdocs/security-7.xml (original) +++ tomcat/site/trunk/xdocs/security-7.xml Fri Aug 20 06:35:37 2010 @@ -25,11 +25,14 @@ mailto:secur...@tomcat.apache.org";>Tomcat Security Team. - - - Note: These issues will be fixed in 7.0.1 but that version has not - yet been released. + +Note: The issue below was fixed in Apache Tomcat 7.0.1 but the + release vote for the 7.0.1 release candidate did not pass. Therefore, + although users must download 7.0.2 to obtain a version that includes a + fix for this issue, version 7.0.2 is not included in the list of + affected versions. + Important: Remote Denial Of Service and Information Disclosure Vulnerability http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2227";> - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[ANN] Apache Tomcat 7.0.2 beta released
The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.2 beta. Apache Tomcat 7.0 includes new features over Apache Tomcat 6.0, including support for the new Servlet 3.0, JSP 2.2 and EL 2.2 specifications, web application memory leak detection and prevention, improved security for the Manager and Host Manager applications, Generic CSRF protection, support for including external content directly in a web application (aliases), re-factoring (connectors, life-cycle) and lots of internal code clean-up. The 7.0.2 release contains numerous bug fixes and an important security fix compared to 7.0.0. Please refer to the change log for the list of changes: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Note that this version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures. Downloads: http://tomcat.apache.org/download-70.cgi Migration guide from Apache Tomcat 5.5.x and 6.0.x: http://tomcat.apache.org/migration.html Thank you, -- The Apache Tomcat Team - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
