Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Wed, 21 Dec 2011 19:05:33 +0000 (UTC)
From: "Clinton Nielsen (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: 
 <1799739763.36554.1324494333924.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <2091560635.32146.1324409311146.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (HTTPCLIENT-1152)
 org.apache.http.impl.client.cache.memcached.MemcachedHttpCacheStorage
 should verify class of returned object before casting
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174304#comment-13174304 ] 

Clinton Nielsen edited comment on HTTPCLIENT-1152 at 12/21/11 7:04 PM:
-----------------------------------------------------------------------

>> In my case, it is that we are using jmemcacheddaemon for local testing purposes, and (unfortunately) jmemcacheddaemon has 
>> a known bug where cache misses return an empty string instead of a null object. 

>OK. But I do not think that polluting a general purpose library with a hack clearly specific to your local environment is the right thing to do. Simply implement a custom HttpCacheStorage which is aware of the empty string semantics. 

Fair enough. But as a general principle, if memcached ever retrieves an object that isn't the expected type, it should count as a cache-miss. It certainly shouldn't throw a ClassCastException. Just 'miss' and move on.


--- I actually had already extended MemcachedHttpCacheStorage to make it aware of the empty-string problem, and also to hash URLs using SHA-512, and to allow a custom prefix on the keys. So I'm good. I just opened these bugs so you could be aware and make changes if you want.  :)
                
      was (Author: tinclon):
    >> In my case, it is that we are using jmemcacheddaemon for local testing purposes, and (unfortunately) jmemcacheddaemon has 
>> a known bug where cache misses return an empty string instead of a null object. 

>OK. But I do not think that polluting a general purpose library with a hack clearly specific to your local environment is the right thing to do. Simply implement a custom HttpCacheStorage which is aware of the empty string semantics. 

Fair enough. But as a general principle, if memcached ever retrieves an object that isn't the expected type, it should count as a cache-miss. It certainly shouldn't throw a ClassCastException. Just 'miss' and move on.
                  
> org.apache.http.impl.client.cache.memcached.MemcachedHttpCacheStorage should verify class of returned object before casting
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1152
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1152
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: Cache, HttpClient
>    Affects Versions: 4.1.1
>            Reporter: Clinton Nielsen
>            Assignee: Jon Moore
>         Attachments: HTTPCLIENT-1152.patch
>
>
> org.apache.http.impl.client.cache.memcached.MemcachedHttpCacheStorage
> Original (in getEntry function): 
>   byte[] data = (byte[]) client.get(url);
> Should be:
>   Object obj= client.get(url);
>   if (null == obj || !(objinstanceof byte[])) {
>     return null;
>   }
>   byte[] data = (byte[])obj;
> Original (in updateEntry function):
>   byte[] oldBytes = (v != null) ? (byte[]) v.getValue() : null;
> Should be:
>   byte[] oldBytes = (v != null && (v.getValue() instanceof byte[])) ? (byte[]) v.getValue() : null;
>   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

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