commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Eckenfels (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (VFS-441) FileObject.exists - Could not determine the type of the file
Date Wed, 21 May 2014 18:31:40 GMT

    [ 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)

Mime
View raw message