[
https://issues.apache.org/jira/browse/HTTPCORE-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843968#comment-16843968
]
ASF subversion and git services commented on HTTPCORE-578:
----------------------------------------------------------
Commit 32c9a0930288fac208a02ee0a84e4607899c499c in httpcomponents-core's branch
refs/heads/master from Gary Gregory
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-core.git;h=32c9a09 ]
(HTTPCORE-578) Incorrect serialization of HeaderGroup (#127)
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
