Archiva
  1. Archiva
  2. MRM-631

network proxy is always used when defined

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.1.1
    • Component/s: remote proxy
    • Labels:
      None
    • Environment:
      Linux and Windows with JRE 1.5
    • Number of attachments :
      1

      Description

      I've installed Archiva 1.0 as a Maven proxy repository for internet and corporate repositories.
      I've added the remote Internet Repositories, the network proxy and the proxy connectors.

      It works well for the internet repositories but when Archiva tries to connect to the corporate repository in the same subnetwork, Archiva uses
      the network proxy despite the proxy connector is set to Direct Connection.

      If no proxy connectors is defined, Archiva didn't try to get data form the corporate repository.

      If no network proxy is defined, Archiva can contact the corporate repository but not the Internet ones.

      I've done a test with network capture (wireshark ex ethereal) to confirm the network proxy defined is used. And the result confirm my opinion, the proxy is used.

      I attach the archiva.xml configuration file in order to check it.
      The corporate repository is localrepo and is available in http form the archiva server using lynx, wget and telnet.

      Thanks for your help

      1. archiva.xml
        5 kB
        Jacques REYNARD

        Activity

        Hide
        Arnaud Heritier added a comment -

        I have the same issue, but I found a workaround.
        In my case I have some real external repositories which are behind an http proxy and some local repositories using file:// protocol.
        If I order proxy connectors with external repositories first, my local repositories aren't read and I have an error from my http proxy. If I put my local repositories first, everything is fine.

        Show
        Arnaud Heritier added a comment - I have the same issue, but I found a workaround. In my case I have some real external repositories which are behind an http proxy and some local repositories using file:// protocol. If I order proxy connectors with external repositories first, my local repositories aren't read and I have an error from my http proxy. If I put my local repositories first, everything is fine.
        Hide
        Brett Porter added a comment -

        I've not been able to reproduce this with 1.0.2-SNAPSHOT following the instructions in both comments. Arnaud, are you able to try the snapshot and check whether we've fixed this with some other changes?

        Show
        Brett Porter added a comment - I've not been able to reproduce this with 1.0.2-SNAPSHOT following the instructions in both comments. Arnaud, are you able to try the snapshot and check whether we've fixed this with some other changes?
        Hide
        Arnaud Heritier added a comment -

        I don't know, but it's fixed in current SNAPSHOT

        Show
        Arnaud Heritier added a comment - I don't know, but it's fixed in current SNAPSHOT
        Hide
        Brett Porter added a comment - - edited

        it has been reported on list that this is still a problem. It may be an issue with the system properties. a potential workaround for this is to use the -Dhttp.nonProxyHosts in the startup script (or wrapper.conf). IF that doesn't work, try replacing wagon-http-lightweight with wagon-http.

        Show
        Brett Porter added a comment - - edited it has been reported on list that this is still a problem. It may be an issue with the system properties. a potential workaround for this is to use the -Dhttp.nonProxyHosts in the startup script (or wrapper.conf). IF that doesn't work, try replacing wagon-http-lightweight with wagon-http.
        Hide
        Olaf Fricke added a comment -

        I have fought against the same problem last week and finally found a solution.

        We have the same setup as described above in our company: we have a local maven2 repository that is used as server for our own artifacts. This repository needs to be reached directly. In addition, we are using a couple of remote repositories in the internet. To reach these repositories, a network proxy has to be used.

        We are using archiva 1.0.2 as mirror in the maven configuration to proxy all these repositories. Everything works fine, as long as we are using either the local repository without a proxy only or the remote repositories behind the network proxy. Using both kinds of repositories results in strange error messages.

        After hours of testing, researching and even code reviews I found the problem: as soon as a network proxy is defined on the archiva configuration page, saving a proxy connector the used direct connection via the archiva configuration changes the archiva.xml configuration file. Instead of the usual empty <proxyId/> tag, the configuration file contains <proxyId>(direct connection)</proxyId>. And this does not work.

        After I have removed the the '(direct connection)' manually from the configuration file the mixed setup is working!

        Show
        Olaf Fricke added a comment - I have fought against the same problem last week and finally found a solution. We have the same setup as described above in our company: we have a local maven2 repository that is used as server for our own artifacts. This repository needs to be reached directly. In addition, we are using a couple of remote repositories in the internet. To reach these repositories, a network proxy has to be used. We are using archiva 1.0.2 as mirror in the maven configuration to proxy all these repositories. Everything works fine, as long as we are using either the local repository without a proxy only or the remote repositories behind the network proxy. Using both kinds of repositories results in strange error messages. After hours of testing, researching and even code reviews I found the problem: as soon as a network proxy is defined on the archiva configuration page, saving a proxy connector the used direct connection via the archiva configuration changes the archiva.xml configuration file. Instead of the usual empty <proxyId/> tag, the configuration file contains <proxyId>(direct connection)</proxyId>. And this does not work. After I have removed the the '(direct connection)' manually from the configuration file the mixed setup is working!
        Hide
        Brett Porter added a comment -

        the configuration file isn't the issue here.

        There are two problems:
        1) the wagons were not being re-initialised, meaning the first used remote proxy stuck forever
        2) the lightweight-http-wagon being used did not reset the system properties after use

        The first is fixed. The second has been worked around.

        Note that the second is highly likely to be a problem if you have concurrent requests accessing both, however I'm reluctant to add synchronisation just for that purpose. It would be better for us to invest in switching to commons-httpclient again in 1.2 so this becomes a non-issue.

        Show
        Brett Porter added a comment - the configuration file isn't the issue here. There are two problems: 1) the wagons were not being re-initialised, meaning the first used remote proxy stuck forever 2) the lightweight-http-wagon being used did not reset the system properties after use The first is fixed. The second has been worked around. Note that the second is highly likely to be a problem if you have concurrent requests accessing both, however I'm reluctant to add synchronisation just for that purpose. It would be better for us to invest in switching to commons-httpclient again in 1.2 so this becomes a non-issue.
        Hide
        Brian Jackson added a comment -

        Brett, if there is a known issue with lightweight-http-wagon, why is this issue closed? I'm still experiencing it in 1.1.1. This issue should be open with the workarounds clearly listed for those of us running into it, please.

        Show
        Brian Jackson added a comment - Brett, if there is a known issue with lightweight-http-wagon, why is this issue closed? I'm still experiencing it in 1.1.1. This issue should be open with the workarounds clearly listed for those of us running into it, please.
        Hide
        Arnaud Heritier added a comment -

        What I understood is that the workaround is in archiva's code. That's why Brett closed it.

        Show
        Arnaud Heritier added a comment - What I understood is that the workaround is in archiva's code. That's why Brett closed it.
        Hide
        Brian Jackson added a comment -

        Thanks Arnaud, maybe that's my confusion in understanding the comments on this issue. But like I said, I'm still experiencing it with 1.1.1 so its not fixed if its a workaround in the code base. I didn't have the -Dhttp.nonProxyHosts set so I'm trying that and hopefully that's the workaround Brett was referring to. I'll also try the http wagon if it doesn't work. I know I tried that under Archiva 1.0.1 and it hosed my instance so I'm hesitant to try it.

        Show
        Brian Jackson added a comment - Thanks Arnaud, maybe that's my confusion in understanding the comments on this issue. But like I said, I'm still experiencing it with 1.1.1 so its not fixed if its a workaround in the code base. I didn't have the -Dhttp.nonProxyHosts set so I'm trying that and hopefully that's the workaround Brett was referring to. I'll also try the http wagon if it doesn't work. I know I tried that under Archiva 1.0.1 and it hosed my instance so I'm hesitant to try it.
        Hide
        Brett Porter added a comment -

        we were using the http wagon for a while but encountered some deadlocking in the version of httpclient. I believe there's an open issue for switching to something else (we're now looking at the jetty http client), which is why I closed this one. The obvious bug was fixed, with limitations.

        Are you experiencing it in all cases, or only on concurrent access to both proxied and non-proxied repos?

        Show
        Brett Porter added a comment - we were using the http wagon for a while but encountered some deadlocking in the version of httpclient. I believe there's an open issue for switching to something else (we're now looking at the jetty http client), which is why I closed this one. The obvious bug was fixed, with limitations. Are you experiencing it in all cases, or only on concurrent access to both proxied and non-proxied repos?
        Hide
        Brian Jackson added a comment -

        I experience it after Archiva has been up for some time. For 1.0.2 it was only about 5 minutes, for 1.1.1 it was good for about 3 days. After that point it will switch to always using the proxy server even for remote repos configured to use direct connect. The concurrency of the access is not an issue since after this issue happens it will happen consistently until a restart even with no other users accessing the server.

        Show
        Brian Jackson added a comment - I experience it after Archiva has been up for some time. For 1.0.2 it was only about 5 minutes, for 1.1.1 it was good for about 3 days. After that point it will switch to always using the proxy server even for remote repos configured to use direct connect. The concurrency of the access is not an issue since after this issue happens it will happen consistently until a restart even with no other users accessing the server.
        Hide
        Brett Porter added a comment -

        Perhaps it is triggered by an exception that doesn't reset the properties. Would you mind creating a new issue for us to investigate this specifically?

        Show
        Brett Porter added a comment - Perhaps it is triggered by an exception that doesn't reset the properties. Would you mind creating a new issue for us to investigate this specifically?
        Hide
        Brian Jackson added a comment -

        Brett, I created MRM-909.

        Show
        Brian Jackson added a comment - Brett, I created MRM-909 .

          People

          • Assignee:
            Brett Porter
            Reporter:
            Jacques REYNARD
          • Votes:
            6 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: