Skip to main content
[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

Back to the top