Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <23042907.532931279859870049.JavaMail.jira@thor>
Date: Fri, 23 Jul 2010 00:37:50 -0400 (EDT)
From: "David Smiley (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Subject: [jira] Updated: (HTTPCLIENT-969) BasicCookieStore.getCookies()
 returns non-threadsafe collection
In-Reply-To: <22340124.471211279608169970.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HTTPCLIENT-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Smiley updated HTTPCLIENT-969:
------------------------------------

    Attachment: HTTPCLIENT-969_Fix_CookieStore_Thread-Safety.patch

Attached is the patch addressing my comments.  There's no longer a need for an instance of the CookieComparator to be a field value so I removed it.  I also saw that toString() should be synchronized.  I also removed the simplistic no-arg constructor since Java will generate the same thing from field initializers.  I hate needlessly verbose Java code -- it gives the language a bad reputation.

> BasicCookieStore.getCookies() returns non-threadsafe collection
> ---------------------------------------------------------------
>
>                 Key: HTTPCLIENT-969
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-969
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>            Reporter: David Smiley
>            Priority: Minor
>             Fix For: 4.0.2, 4.1 Alpha3
>
>         Attachments: HTTPCLIENT-969_Fix_CookieStore_Thread-Safety.patch
>
>
> BasicCookieStore.getCookies() is a simple method.  It's synchronized, and it returns an unmodifiable wrapper around the underlying cookie list.  If the caller were to then iterate over it as another thread were to manipulate the cookie list via BasicCookieStore, this would create a thread un-safe situation because both threads aren't doing their reading/writing with the same lock (the reader doesn't even have a lock).
> I suggest fixing this by using CopyOnWriteArrayList, or by making a defensive copy in getCookies()
> This issue might apply to some of the other basic implementations of some of the interfaces but I haven't checked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org