[
https://issues.apache.org/jira/browse/VFS-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14005053#comment-14005053
]
Bernd Eckenfels commented on VFS-441:
-------------------------------------
Hello, I think the Bug is invalid (as I will explain below), but to avoid
re-opening it, I have a number of questions to better understand what you are
reporting:
a) you have a web server (application) and a java application which is running
VFS. I will call this second application "client". Is this the same or
different processes?
b) how long does the client access the server with no HEAD errors? How long
(time) and how many requests (roughly) are processed sucessfully until then?
c) if the requests start to fail, will all requests fail or only a few randomly?
d) what is the application you access, what is it doing to provide the data?
what do you see in the web server access and error log?
e) you say "restart", are you talking about the web server, the client or both?
if you restart both, try to restart only one and tell us if it helps.
f) when it starts to fail and before restart take a look at the open
connections between both applications (netstat -tn | ESTABLISHED).
So here is the thing: the exception you have shown is thrown whenever a HTTP
HEAD request is ansewered by the server with an unexpected error code. It
expects 200 (file is there) or 404/301 (file is not there). Everything else
will result in the above exception. The newer version of VFS will actually
write the error code in the exception, but you should already be able to see
the error in the web server logs.
One likely error code could be 500 internal error because of some programing
error in the web app (for example resource leak). It could also be an overload
situation or similiar, all not directly related or fixable in VFS.
As for your question on close: no I dont think it is required or will help. The
only thing I could imagine which makes your web server create more errors is
the number of open connections. This is lomited by the http pool (can be
configured). Closing is not the right solution if you app is limited, reduce
the number of connections per host.
Please answer all a-f questions above, otherwise we cant help. If it turns out
the problem is not in VFS I would recommend you discuss it further on the
users@commoins mailinglist (not in this bug). I am waiting for your answers
before I close it (again).
> FileObject.exists - Could not determine the type of the file
> ------------------------------------------------------------
>
> Key: VFS-441
> URL: https://issues.apache.org/jira/browse/VFS-441
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 1.0
> Reporter: vijayan
> Priority: Critical
>
> Hi,
> We are using common-vfs-1.0.jar. And it used to work fined. But on and off in
> a random manner, we get the following exception
> org.apache.commons.vfs.FileSystemException: Could not determine the type of
> file "https://.....";.
> at
> org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1305)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject.java:412)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.exists(AbstractFileObject.java:402)
> Caused by: org.apache.commons.vfs.FileSystemException: HEAD method failed for
> "https://....";.
> at
> org.apache.commons.vfs.provider.http.HttpFileObject.doGetType(HttpFileObject.java:96)
> at
> org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.java:1296)
> Restarting the server will work smoothly. But why this error occuring , any
> help would be appreciated. Thanks in advance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
