Attribute Filter hangs when resource not found for file-backed http resource is used
Description
Environment
Attachments
is related to
Activity
For the OP : it should be possible to fix an IdP by replacing spring-extensions-5.2.0.jar with a snapshot of spring-extensions-5.3.0 from 2016-04-21 [1].
In your $idp.home/webapp
directory, you will need to remove spring-extensions-5.2.0.jar and replace it with spring-extensions-5.3.0-20160421.040242-126.jar, then run bin/build.sh
and redeploy.
The latter calls the former. So by the time the call finishes and the latter gets the return value, the response is already closed. So it doesn't need to do it.
I think you're looking at getResourceHeaders() which has a finally block, not getResponseHeader(String), which does not.
Will open a new issue on this but: I was looking into to confirm what actually happens per the Javadocs. Rod also commented to me oob that he thought the Javadocs are wrong here. The seem to be. The default builder produces RequestConfig
with -1 for all 3, but in the consuming code that pulls the values they do this for connectionRequestTimeout
and connectTimeout
when passing on:
timeout > 0 ? timeout : 0
And in those I think 0 is infinite.
For socketTimeout
they do:
final int timeout = config.getSocketTimeout();
if (timeout >= 0) {
managedConn.setSocketTimeout(timeout);
}
so don't set at all when -1, which means it does some default thing. Still researching, but that could the the Java Socket
default which could be non-infinite.
And of course all this might be different in the later minor versions. So this needs a new issue.
It actually already does, in the finally block. The only thing I see so far that wasn't closing was what you already fixed in the getInputStream(), the non-200 status case.
If a remote resource is used as an attribute filter file and the file does not exist, the attribute filter service fails to reload completely. It succeeds on start-up and on the first automatic or manual reload after start-up. After that, it hangs and never completes. I'm not sure if it's the service hangin g or the http client pool running out of connections.