[jira] [Updated] (HTTPCLIENT-1165) Cache allows multipe requests to retrieve the same cacheable resource from the server in multithreaded environment due to lack of proper locking
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-1165:
--
Labels: stuck volunteers-wanted (was: )
Fix Version/s: (was: Future)
Stuck
> Cache allows multipe requests to retrieve the same cacheable resource from
> the server in multithreaded environment due to lack of proper locking
>
>
> Key: HTTPCLIENT-1165
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1165
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpCache
>Affects Versions: Snapshot
>Reporter: Manish Tripathi
> Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> Consider the following scenario:
> Two separate threads are launched at the same time with identical Http
> requests through CachingHttpClient.
> Both threads look up the same URI in the cache at [almost] the same time and
> find no cached response for that URI.
> Both threads fall back to backend HttpClient and make identical requests to
> the server.
> Both threads retrieve the resource and attempt to store it in the cache.
> The same resource gets retrieved from the server twice and is stored in the
> cache twice.
> Obviously, the described algorithm is inefficient
> Suggested fix: introduce read-write locking mechanism which would block
> multiple requests to retrieve the same URI until one of the concurrent
> requests has either received a response header indicating that the response
> is not cacheable, or until cacheable response has been fully retrieved and
> stored in the cache. The proposed pseudo-code follows:
> cachingClient.execute(url) {
> if (lock_count(url)>0)
> lock=lockingFactory.acquireReadLock(url);
> else
> lock=lockingFactory.acquireWriteLock(url);
> response=satisfyFromCache(url);
> if (response==null) {
> if (lock.isReadLock()) { lock.release();
> lock=lockingFactory.acquireWriteLock(url); }
> response=satisfyFromServerAndStoreInCache(url);
> }
> lock.release();
> return response;
> }
> where lockingFactory instance is shared by multiple instances of
> CachingHttpClient.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1165) Cache allows multipe requests to retrieve the same cacheable resource from the server in multithreaded environment due to lack of proper locking
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-1165:
--
Fix Version/s: Future
Cache allows multipe requests to retrieve the same cacheable resource from
the server in multithreaded environment due to lack of proper locking
Key: HTTPCLIENT-1165
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1165
Project: HttpComponents HttpClient
Issue Type: Improvement
Components: Cache
Affects Versions: Snapshot
Reporter: Manish Tripathi
Fix For: Future
Consider the following scenario:
Two separate threads are launched at the same time with identical Http
requests through CachingHttpClient.
Both threads look up the same URI in the cache at [almost] the same time and
find no cached response for that URI.
Both threads fall back to backend HttpClient and make identical requests to
the server.
Both threads retrieve the resource and attempt to store it in the cache.
The same resource gets retrieved from the server twice and is stored in the
cache twice.
Obviously, the described algorithm is inefficient
Suggested fix: introduce read-write locking mechanism which would block
multiple requests to retrieve the same URI until one of the concurrent
requests has either received a response header indicating that the response
is not cacheable, or until cacheable response has been fully retrieved and
stored in the cache. The proposed pseudo-code follows:
cachingClient.execute(url) {
if (lock_count(url)0)
lock=lockingFactory.acquireReadLock(url);
else
lock=lockingFactory.acquireWriteLock(url);
response=satisfyFromCache(url);
if (response==null) {
if (lock.isReadLock()) { lock.release();
lock=lockingFactory.acquireWriteLock(url); }
response=satisfyFromServerAndStoreInCache(url);
}
lock.release();
return response;
}
where lockingFactory instance is shared by multiple instances of
CachingHttpClient.
--
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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1165) Cache allows multipe requests to retrieve the same cacheable resource from the server in multithreaded environment due to lack of proper locking
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manish Tripathi updated HTTPCLIENT-1165:
Component/s: Cache
Description:
Consider the following scenario:
Two separate threads are launched at the same time with identical Http requests
through CachingHttpClient.
Both threads look up the same URI in the cache at [almost] the same time and
find no cached response for that URI.
Both threads fall back to backend HttpClient and make identical requests to the
server.
Both threads retrieve the resource and attempt to store it in the cache.
The same resource gets retrieved from the server twice and is stored in the
cache twice.
Obviously, the described algorithm is inefficient
Suggested fix: introduce read-write locking mechanism which would block
multiple requests to retrieve the same URI until one of the concurrent requests
has either received a response header indicating that the response is not
cacheable, or until cacheable response has been fully retrieved and stored in
the cache. The proposed pseudo-code follows:
cachingClient.execute(url) {
if (lock_count(url)0)
lock=lockingFactory.acquireReadLock(url);
else
lock=lockingFactory.acquireWriteLock(url);
response=satisfyFromCache(url);
if (response==null) {
if (lock.isReadLock()) { lock.release();
lock=lockingFactory.acquireWriteLock(url); }
response=satisfyFromServerAndStoreInCache(url);
}
lock.release();
return response;
}
where lockingFactory instance is shared by multiple instances of
CachingHttpClient.
Affects Version/s: Snapshot
Summary: Cache allows multipe requests to retrieve the same
cacheable resource from the server in multithreaded environment due to lack of
proper locking (was: Cache allows multipe requests to retrieve the same
cacheable resource from the server in multithreaded environment )
Cache allows multipe requests to retrieve the same cacheable resource from
the server in multithreaded environment due to lack of proper locking
Key: HTTPCLIENT-1165
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1165
Project: HttpComponents HttpClient
Issue Type: Bug
Components: Cache
Affects Versions: Snapshot
Reporter: Manish Tripathi
Consider the following scenario:
Two separate threads are launched at the same time with identical Http
requests through CachingHttpClient.
Both threads look up the same URI in the cache at [almost] the same time and
find no cached response for that URI.
Both threads fall back to backend HttpClient and make identical requests to
the server.
Both threads retrieve the resource and attempt to store it in the cache.
The same resource gets retrieved from the server twice and is stored in the
cache twice.
Obviously, the described algorithm is inefficient
Suggested fix: introduce read-write locking mechanism which would block
multiple requests to retrieve the same URI until one of the concurrent
requests has either received a response header indicating that the response
is not cacheable, or until cacheable response has been fully retrieved and
stored in the cache. The proposed pseudo-code follows:
cachingClient.execute(url) {
if (lock_count(url)0)
lock=lockingFactory.acquireReadLock(url);
else
lock=lockingFactory.acquireWriteLock(url);
response=satisfyFromCache(url);
if (response==null) {
if (lock.isReadLock()) { lock.release();
lock=lockingFactory.acquireWriteLock(url); }
response=satisfyFromServerAndStoreInCache(url);
}
lock.release();
return response;
}
where lockingFactory instance is shared by multiple instances of
CachingHttpClient.
--
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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1165) Cache allows multipe requests to retrieve the same cacheable resource from the server in multithreaded environment due to lack of proper locking
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Moore updated HTTPCLIENT-1165:
--
Issue Type: Improvement (was: Bug)
@Manish: I've reclassified this as an improvement and not a bug, as the cache
properly handles these race conditions if multiple responses have differing
Date headers, so no semantic transparency is broken here--in other words no
incorrect HTTP behavior is created by the cache.
That said, request collapsing is a perfectly valid enhancement request--patches
welcome. :)
Cache allows multipe requests to retrieve the same cacheable resource from
the server in multithreaded environment due to lack of proper locking
Key: HTTPCLIENT-1165
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1165
Project: HttpComponents HttpClient
Issue Type: Improvement
Components: Cache
Affects Versions: Snapshot
Reporter: Manish Tripathi
Consider the following scenario:
Two separate threads are launched at the same time with identical Http
requests through CachingHttpClient.
Both threads look up the same URI in the cache at [almost] the same time and
find no cached response for that URI.
Both threads fall back to backend HttpClient and make identical requests to
the server.
Both threads retrieve the resource and attempt to store it in the cache.
The same resource gets retrieved from the server twice and is stored in the
cache twice.
Obviously, the described algorithm is inefficient
Suggested fix: introduce read-write locking mechanism which would block
multiple requests to retrieve the same URI until one of the concurrent
requests has either received a response header indicating that the response
is not cacheable, or until cacheable response has been fully retrieved and
stored in the cache. The proposed pseudo-code follows:
cachingClient.execute(url) {
if (lock_count(url)0)
lock=lockingFactory.acquireReadLock(url);
else
lock=lockingFactory.acquireWriteLock(url);
response=satisfyFromCache(url);
if (response==null) {
if (lock.isReadLock()) { lock.release();
lock=lockingFactory.acquireWriteLock(url); }
response=satisfyFromServerAndStoreInCache(url);
}
lock.release();
return response;
}
where lockingFactory instance is shared by multiple instances of
CachingHttpClient.
--
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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
