You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Scott W Gifford (Jira)" <ji...@apache.org> on 2019/11/20 03:18:00 UTC
[jira] [Comment Edited] (HTTPCORE-578) Incorrect serialization of
HeaderGroup
[ https://issues.apache.org/jira/browse/HTTPCORE-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16978033#comment-16978033 ]
Scott W Gifford edited comment on HTTPCORE-578 at 11/20/19 3:17 AM:
--------------------------------------------------------------------
[~olegk] We have faced a similar problem, and are working on a new serializer that is more robust than Java Object serialization.
What sorts of requirements would you have for accepting it back as a contribution to the project? For example right now our serializer is using Jackson and the BSON plugin, would you accept something with those dependencies back into the project, or it's too heavyweight?
Thanks!
----Scott.
was (Author: sgifford):
[~olegk] We have faced a similar problem, and are working on a new serializer that is more robust than the Java Object serialization.
What sorts of requirements would you have for accepting it back as a contribution to the project? For example right now our serializer is using Jackson and the BSON plugin, would you accept something with those dependencies back into the project, or it's too heavyweight?
Thanks!
----Scott.
> 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