You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by "Stallard,David" <st...@oclc.org> on 2014/07/14 19:32:55 UTC

Some questions now that we're running Archiva 2.0.1

Now that we have upgraded from 1.3.5 to 2.0.1, some questions have come up:


  1.  Is there a way to stop a repository scan once it has started?  It looks like a full scan of internal started when we brought up the new version, and due to the size of our repository (and possibly insufficient hardware), it took over 48 hours to complete.  We started a similar scan on snapshots once internal was complete, just in case that is optimal for 2.0.1, and it has been running for almost 72 hours.  We don't necessarily want to stop it, but it would be good to know how in case we need to...these scans do affect overall performance.  We haven't tried bouncing Archiva, not sure if that would stop the scan or if it would just resume upon startup.
  2.  Is there a way to disable a proxy?  In 1.3.5 we would sometimes find that proxy repositories would become unresponsive and time out on every request (sometimes this happens even if the proxy if available via manual browser URL), and Archiva is effectively hung until the timeout finally completes.  In these cases we would disable the proxy and then try turning it back on at some later date to see if it is behaving better.  This has already happened once in 2.0.1 and since we couldn't find a way to disable it, we just deleted that proxy.
  3.

Re: Some questions now that we're running Archiva 2.0.1

Posted by "Stallard,David" <st...@oclc.org>.
If I can follow up on my own question #1...  After further digging it appears that what might be taking so long for these scans to happen, and why disk usage has increased dramatically, is because it is populating the jcr repository for the first time.  It looks like jcr was introduced in 1.4-M1 and we are coming from 1.3.5, so we haven't encountered it until now.  Does it sound correct that the initial population of the jcr repository would cause long scan times and increase overall disk usage significantly?

We have found that data/archiva/database is holding a large amount of data and none of it has a timestamp more recent than when we shut down 1.3.5 in order to do the 2.0.1 upgrade.  So, has data/archiva/database been replaced by data/jcr?  If so, we could delete data/archiva/database and reclaim a significant amount of disk space.

Thanks,
David

From: <Stallard>, "Stallard,David" <st...@oclc.org>>
Date: Monday, July 14, 2014 at 1:48 PM
To: "users@archiva.apache.org<ma...@archiva.apache.org>" <us...@archiva.apache.org>>
Subject: Re: Some questions now that we're running Archiva 2.0.1

Sorry, I hit the wrong hotkey combo and my message was sent prematurely.  Let's just start with the two questions below, though.

Thanks,
David

From: <Stallard>, "Stallard,David" <st...@oclc.org>>
Date: Monday, July 14, 2014 at 1:27 PM
To: "users@archiva.apache.org<ma...@archiva.apache.org>" <us...@archiva.apache.org>>
Subject: Some questions now that we're running Archiva 2.0.1

Now that we have upgraded from 1.3.5 to 2.0.1, some questions have come up:


  1.  Is there a way to stop a repository scan once it has started?  It looks like a full scan of internal started when we brought up the new version, and due to the size of our repository (and possibly insufficient hardware), it took over 48 hours to complete.  We started a similar scan on snapshots once internal was complete, just in case that is optimal for 2.0.1, and it has been running for almost 72 hours.  We don't necessarily want to stop it, but it would be good to know how in case we need to...these scans do affect overall performance.  We haven't tried bouncing Archiva, not sure if that would stop the scan or if it would just resume upon startup.
  2.  Is there a way to disable a proxy?  In 1.3.5 we would sometimes find that proxy repositories would become unresponsive and time out on every request (sometimes this happens even if the proxy if available via manual browser URL), and Archiva is effectively hung until the timeout finally completes.  In these cases we would disable the proxy and then try turning it back on at some later date to see if it is behaving better.  This has already happened once in 2.0.1 and since we couldn't find a way to disable it, we just deleted that proxy.
  3.

Re: Some questions now that we're running Archiva 2.0.1

Posted by "Stallard,David" <st...@oclc.org>.
Sorry, I hit the wrong hotkey combo and my message was sent prematurely.  Let's just start with the two questions below, though.

Thanks,
David

From: <Stallard>, "Stallard,David" <st...@oclc.org>>
Date: Monday, July 14, 2014 at 1:27 PM
To: "users@archiva.apache.org<ma...@archiva.apache.org>" <us...@archiva.apache.org>>
Subject: Some questions now that we're running Archiva 2.0.1

Now that we have upgraded from 1.3.5 to 2.0.1, some questions have come up:


  1.  Is there a way to stop a repository scan once it has started?  It looks like a full scan of internal started when we brought up the new version, and due to the size of our repository (and possibly insufficient hardware), it took over 48 hours to complete.  We started a similar scan on snapshots once internal was complete, just in case that is optimal for 2.0.1, and it has been running for almost 72 hours.  We don't necessarily want to stop it, but it would be good to know how in case we need to...these scans do affect overall performance.  We haven't tried bouncing Archiva, not sure if that would stop the scan or if it would just resume upon startup.
  2.  Is there a way to disable a proxy?  In 1.3.5 we would sometimes find that proxy repositories would become unresponsive and time out on every request (sometimes this happens even if the proxy if available via manual browser URL), and Archiva is effectively hung until the timeout finally completes.  In these cases we would disable the proxy and then try turning it back on at some later date to see if it is behaving better.  This has already happened once in 2.0.1 and since we couldn't find a way to disable it, we just deleted that proxy.
  3.