|
|
| Re: TimeoutInputStream suffered IO error [message #625278 is a reply to message #625274] |
Sat, 26 June 2010 21:25  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Meng,
Meng Xin Zhu wrote:
> My application is based on p2, so it indirectly consumes ecf.
>
> Now the application tried to install something from repository, and the
> repository locates in a mount point that is mounted from remote server.
>
> However ECF met below io errors while copying the file to cache folder,
> whose size is 800+ MB.
Is this repeatable with this file on some network, or did it happen just
a single time?
> I guess it might be caused by unstable network traffic, how about using
> the 'retry' mechanism of httpclient to avoid it?
So, first of all...I think that you are probably using the
UrlConnection-based filetransfer provider...as the httpclient-based
filetransfer provider does not use TimeoutInputStream (and I see from
the stack trace that TimeoutInputStream is being used for this file
transfer).
I would suggest first that you use the httpclient-based provider instead
of the UrlConnection-based provider. The httpclient-based provider is
present in org.eclipse.ecf.provider.httpclient (and
org.eclipse.ecf.provider.httpclient.ssl).
Eclipse/p2 come with the httpclient provider (as well as the
UrlConnection-based provider)...so it should be as simple as adding the
o.e.e.provider.httpclient/ssl to your p2-based product. If both the
UrlConnection provider and the httpclient provider are present, the
httpclient provider will be preferred.
This might/probably will solve this issue completely, as the
httpclient-based provider has historically been more reliable than the
UrlConnection/jre-based provider...and that's why it's used in Eclipse/p2.
Now, there are also a number of timeout parameters that can be adjusted
for your particular app/use case.
http://wiki.eclipse.org/Equinox/p2/TransportDebugging
I believe there is also a retry capability built into the p2 usage of
ECF, but I don't think it's turned on by default. To find out for sure,
I suggest sending email to p2-dev at eclipse.org. The author of this
part of p2 was Henrick Lindberg I believe.
>Is there anything we
> can do besides bless no network issue during transferring the huge file?
Yes, see above.
As a further option you can/could introduce your own/new provider for
use with your particular app requirements. You could also base it upon
and/or extend the existing providers (e.g. httpclient-based provider),
if you like. If you decide to do this, it might be a good idea to
contribute this as an enhancement (to ECF/p2).
In general, we don't want to put an automatic retry in place as the
default for all use cases (i.e. Eclipse use of p2) because this will not
be the right strategy for many...perhaps most...failure situations.
Scott
> !SUBENTRY 1 org.eclipse.equinox.p2.repository 4 1002 2010-06-22
> 10:08:01.014
> !MESSAGE Unable to read repository at
> file:/mnt/dvd/images/CDR-R138542.1-1-00/binary/wr-lx-ref-src
> -pkgs-glibc-std-3.0-src.wrlinux-pkgs.common.common.common.co
> mmon.common-all-all_3.0.0.0_200902261413.
> !STACK 0
> java.io.IOException: Input/output error
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:199)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:21 8)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:2 58)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:31 7)
> at org.eclipse.ecf.provider.filetransfer.util.TimeoutInputStrea
> m.readUntilDone(TimeoutInputStream.java:322)
> at org.eclipse.ecf.provider.filetransfer.util.TimeoutInputStrea
> m.runThread(TimeoutInputStream.java:266)
> at org.eclipse.ecf.provider.filetransfer.util.TimeoutInputStrea
> m$1.run(TimeoutInputStream.java:77)
> at java.lang.Thread.run(Thread.java:619)
|
|
|
Powered by
FUDForum. Page generated in 0.03544 seconds
] 
Search
Help
Register
Login
Home
