[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] read timeout problems
|
Hey Ian!
Thanks for the quick reply and the explanations. That helps, but I still
can't figure out what the exact problem is.
Re: the p2.index file. This only instructs p2 for which 'types' of
repositories to load. The 'type' is indexed by a key. In the case of
composite metadata repositories, the key is compositeContent.xml. This
says nothing about the file names to load (these are handled by the
particular extension that implements this repository type). So the file
could bee foo.txt for all we know.
Now, it happens that composite metadata repos check compositeContent.jar
and composÆ’iteContent.xml (and it uses a particular search order, .jar
first I think).
Ok, that makes sense to me and is very good to know. Thanks for the
details a lot!!!
As for the access denied, yes, I know AWS does this (and some consider
this a good security measure, since you can't figure out the difference
between accessed denied and not available). The transport layer
_should_ fail fast in this case and move on to the xml file.
It doesn't seem to be a general problem since I am not able to reproduce
it, but we have a number of users reporting issues with the "check for
updates" and that it is reporting read timeouts or is stalling on
accessing some of those not-really-existing URLs (for which AWS gives
you those access denied XML documents).
Is there an option to turn on for more debug info or so? So that we can
find out what is really going on in this case? Or do you have any other
hints or advice how to find out what is going wrong there (remotely)?
What version of p2 are you using? I know this was a problem a while ago,
but it was fixed (IIRC 3.6.1).
The latest STS builds are based on Indigo 3.7.1, but it could be that
people install it into older Eclipse installations. I will ask them.
Thanks a lot for your help!!! Really highly appreciated!!!!!!!!
-Martin
Cheers,
Ian
On Fri, Jan 6, 2012 at 8:08 AM, Henrik Lindberg
<henrik.lindberg@xxxxxxxxxxxxxx <mailto:henrik.lindberg@xxxxxxxxxxxxxx>>
wrote:
Odd that the information in the p2.index does not seem to be
honoured. Maybe it continues if there is a problem delivering it
(timeout), but I don't really know the logic around the p2.index
file. This is Ian Bull's domain IIRC.
Regarding delivering an access denied status when a not found (404)
should have been delivered is never good as you are basically saying
"the file is there but you are not allowed to read it".
One potential source of problems is if the update site has changed
over time, and user once got hold of index information (in jars or
xml files) that are no longer present - I can imagine checks being
made in those cases for those specific files even if the p2.index
file says otherwise. In this case delivering an access denied
instead of 404 does not give the p2 client side a chance to
correctly update the cached information as it will continue to
believed the file is there. (I am just speculating though).
Hope that is of some help.
Regards
Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx <mailto:henrik.lindberg@xxxxxxxxxxxxxx>
On Jan 6, 2012, at 15:21, Martin Lippert wrote:
Hi!
I am facing an interesting problem with update sites and I hope
you can help me understand what is going on. We have plenty of
composite update sites that all contain just an
"compositeArtifact.xml" and a "compositeContent.xml" file. Those
files work nicely.
But we are quite often getting reports from users that their
installation stalls when they check for updates, complaining about
"content.jar" could not be found (with a read timeout), same for
"compositeArtifact.jar" or similar. Even if I put up a p2.index
file like this:
version=1
metadata.repository.factory.order=compositeContent.xml,!
artifact.repository.factory.order=compositeArtifacts.xml,!
it doesn't change much, the "check for updates" is again
complaining about a missing file "compositeArtifact.jar".
I don't know why and what to do about this.
One thing that is special here is the fact that our server (Amazon
S3) is serving an XML document (containing an access denied error)
when a resource is not found (like it is the case for those
resources that p2 seems to try to download.
Any idea what I can do about this?
Thank you very much in advance for your help!!!
Cheers,
-Martin
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx <mailto:p2-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx <mailto:p2-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/p2-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev