[jira] [Commented] (HTTPCORE-578) Incorrect serialization of HeaderGroup

["Scott W Gifford (Jira)" <ji...@apache.org>]

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

Scott W Gifford commented on HTTPCORE-578:
------------------------------------------

[~olegk] Understood, I have adjusted my approach to use no dependencies, instead using the existing ability to write to HTTP as a serialization mechanism, and the ability to read from HTTP as a deserialization mechanism.  Proposed contribution in [HTTPCORE-615|https://issues.apache.org/jira/projects/HTTPCORE/issues/HTTPCORE-615] and: [https://github.com/apache/httpcomponents-client/pull/187]

 

> Incorrect serialization of HeaderGroup
> --------------------------------------
>
>                 Key: HTTPCORE-578
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-578
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore
>    Affects Versions: 4.4.11, 5.0-beta7
>            Reporter: Eric Hubert
>            Priority: Major
>             Fix For: 4.4.12, 5.0-beta8
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> While updating from HttpClient 4.4.1 to 4.5.8 we immediately faced an issue where the following NPE was thrown.
> {code:java}
> Caused by: java.lang.NullPointerException 
> at org.apache.http.impl.client.cache.CacheValidityPolicy.getAgeValue(CacheValidityPolicy.java:236) 
> at org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedReceivedAgeSecs(CacheValidityPolicy.java:253) 
> at org.apache.http.impl.client.cache.CacheValidityPolicy.getCorrectedInitialAgeSecs(CacheValidityPolicy.java:263) 
> at org.apache.http.impl.client.cache.CacheValidityPolicy.getCurrentAgeSecs(CacheValidityPolicy.java:54) 
> at org.apache.http.impl.client.cache.CacheValidityPolicy.isResponseFresh(CacheValidityPolicy.java:77) 
> at org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.isFreshEnough(CachedResponseSuitabilityChecker.java:76) 
> at org.apache.http.impl.client.cache.CachedResponseSuitabilityChecker.canCachedResponseBeUsed(CachedResponseSuitabilityChecker.java:147) 
> at org.apache.http.impl.client.cache.CachingExec.handleCacheHit(CachingExec.java:291) 
> at org.apache.http.impl.client.cache.CachingExec.execute(CachingExec.java:277) 
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) 
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) 
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) 
> at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) 
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) 
> at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108){code}
> Determining the cause wasn't that obvious, at least not to me. Therefore I thought it would be a good idea to file an issue for documentation purpose. Maybe someone also has a good idea how to address it.
> We use the HttpClient in conjunction with the HttpClient Caching module and configured it to use the Memcached storage (MemcachedHttpCacheStorage). Our memcached infrastructure systems are running all the time, also while we are updating our applications using it. The memcached store serialized representations of HttpCacheEntry. An HttpCacheEntry consists of a HeaderGroup instance (from HttpCore).
> It looks like this class received a change (between HttpCore 4.4.1 and 4.4.2) which changed the serialization, although its serialVersionUID wasn't changed:
> [https://github.com/apache/httpcomponents-core/commit/040af07704592c8acb98a5a47cbf6b90c17fe0e0#diff-5a11091c948c5a8abd9bcc6bb4f7bc0f]
> effectively resulting in an NPE while accessing its new final member EMPTY (which is NULL after deserializing an object created with HttpClient 4.4.1 with a newer version).
> {code:java}
> private final Header[] EMPTY = new Header[] {};{code}
> I have not yet had a chance to check what would have happened, if the serialVersionUID were changed, but I expect the MemcachedHttpCacheStorage to create some sort of SerializationException which may have handled even before in a much more graceful manner. I will test this once I find the time.
> For now we had to do a quick fallback to the old HttpClient version. Next I need to look for a good solution as during rolling software upgrades we will always have a time, were both HttpClient versions are in parallel usage and the response caching seems to be essential (so simply turning off the cache usage during the upgrade, flushing the cache and turning it on once all servers are up with the new HttpClient version also does not seem to be a great option).
> I'm looking forward for any ideas. Please also feel free to adjust/move this ticket accordingly! It turned out not to be a bug in HttpClient Cache itself, but I thought this would be a more logical place than HttpCore as it likely only affects certain Cache usage scenarios.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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