RE: too many open files with 1.0.2
Actually, I think it had to do with the version of derby I was using. The docs said use derby-10.1.3.1.jar or later. I was using derby-10.3.2.1.jar. I changed it do use derby-10.1.3.1.jar and the problem disappeared. It might be a good idea to add a warning or have someone else confirm and then add a warning to the tomcat documentation It caused us a lot of issues and in fact cause our entire primary server to crash. If other people do not have some type of high availability configuration they could really end up in a bind and be quite upset. -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Saturday, April 12, 2008 9:50 AM To: archiva-users@maven.apache.org Subject: Re: too many open files with 1.0.2 I see that also but it was releated to a problem with Tomcat 6.x and libtcnative. Is it your setting ? 2008/4/11, Jason Chaffee [EMAIL PROTECTED]: With Archvia-1.0.2 running in tomcat, I am getting too many open files errors at least twice a day, forcing a reboot of archiva to fix the issue. When I run lsof, I see that the database files are open more than once so I suspect a resource leak. Is anyone else seeing this?
RE: metadata -updater does not appear to be working!
I will file it today. Is there any chance of getting it into a 1.0.2 release? I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:36 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! Hi Jason, Can you file this as a request? I think at present the updater corrects the versions flag, but not the snapshot information (it also doesn't correct the plugin group metadata). - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: According to the documentation the metadata-updater will do the following: metadata-updater - Updates artifact metadata files depending on the content of the repository. I have been testing this by deploying several artifacts to the repository and getting a specific timestamp and build number in the maven-metatadata.xml file. Next, I delete the latest (snapshot) build from the repo, including checksums. I run the repository scanner and the database-updater and this file is never fixed based on the actual contents of the file system. Archive updates it internal metadata, but not maven's metadata and thus maven fails to download the artifact. -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: metadata -updater does not appear to be working!
If the metadata has been updated, then the deploy works fine and the metadata in updated correctly. If the metadata has not been update, the deploy still works fine, but the build numbers get off and there will be missing builds in the repo. I am not sure of other scenarios. We have not encountered any. Deleting files and fixing metatdata files has been a problem for us for awhile and we have had to do it manually in the past, so that it is why it is nice to have this feature in Archiva. However, I would like to see it correct the metatdata file without needing to touch any files after deleting files. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 4:34 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: 1) touching the old jar, seems to work. ok, I'll add that info to the bug 2) I add new builds with maven and not Archiva, and it will increment from the last build number so the next build will not be 4, it will be 6. If, the metatdata file isn't updated first. right - but if the metadata is up to date, then there's no problem? That is, are there scenarios other than deleting builds where the metadata is not updated? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 4:08 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! Ah, sorry I wasn't clear. I was referring to the timestamp on the filesystem - if you touch the JAR you listed and scan again, is the metadata updated? Likewise, does adding a new build instead of removing work? - Brett On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I can confirm that both timestamp and build number are the problem. For example, here is the latest artifact on the file system: test-1.0-2008407.211352-3.jar here is the metatdata file: metadata groupIdchaffee.jason.test/groupId artifactIdtest/artifactId version1.0-SNAPSHOT/version versioning snapshot buildNumber5/buildNumber timestamp20080407.212453/timestamp /snapshot lastUpdated20080407212454/lastUpdated /versioning /metadata -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 08, 2008 3:54 PM To: archiva-users@maven.apache.org Subject: Re: metadata -updater does not appear to be working! On 09/04/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I will file it today. Is there any chance of getting it into a 1.0.2 release? This is being released now, but there's no reason we can't get another release together soon if there are high priority issues. I know that this is extremely important to us. I would even be willing to contribute to with some general guidance where in the code to get started? Hmm, looking at [1] (updateMetadata for VersionReference) it appears that it already does calculate the snapshot version. But the code that calls it in [2] does include a timestamp check that then skips it. Can you confirm whether the timestamp check is the problem? - Brett [1] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-repository-layer/src/main/java/org/apache/maven/archiva/reposit ory/metadata/MetadataTools.java?revision=642426view=markup [2] http://svn.apache.org/viewvc/archiva/branches/archiva-1.0.x/archiva-base /archiva-consumers/archiva-core-consumers/src/main/java/org/apache/maven /archiva/consumers/core/MetadataUpdaterConsumer.java?revision=642426vie w=markup -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: Proxy connectors fails to download, Archiva needs restart
Also, if the artifact is in the local cache and this failure happens, shouldn't is simply log it and then return the cached artifact? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2008 6:29 AM To: archiva-users@maven.apache.org Subject: Re: Proxy connectors fails to download, Archiva needs restart ok, it looks like maybe they've blocked you in some way. Archiva 1.0.2 should improve on the reporting of this, and allows the error handling to be configurable. - Brett On 04/04/2008, Jackson, Brian R [EMAIL PROTECTED] wrote: That didn't take long. Here's the full stacktrace, which implies that the remote repository is returning a 500 error, but if I hit the same URL through a browser I can't reproduce the 500 error. I will coordinate with the owner of the remote repository and see if I can get more info from the logs on his end. 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Path [com/go/tea/tea/3.3.11/tea-3.3.11.pom] is part of blacklist (skipping transfer from repository [Central Repository]). 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [cache-failures] policy with [no] 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:cache-failures - OK to fetch, check-failures policy set to NO. 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [releases] policy with [once] 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:releases - OK to update releases, local file does not exist. 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Applying [snapshots] policy with [never] 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.policies.PreDownloadPolicy:snapshots - OK to update, snapshot policy does not apply for non-snapshot versions. 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - No authentication for remote repository needed 418722 [SocketListener0-1] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Retrieving com/go/tea/tea/3.3.11/tea-3.3.11.pom from WDIG Releases 419035 [SocketListener0-1] WARN org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Transfer error from repository wdig.releases for artifact com.go.tea:tea:3.3.11::pom, continuing to next repository. Error message: Download failure on resource [http://maven2.corp.dig.com:8080/archiva/repository/internal//com/go/tea /tea/3.3.11/tea-3.3.11.pom]:Error transferring file 419035 [SocketListener0-1] DEBUG org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Full stack trace org.apache.maven.archiva.proxy.ProxyException: Download failure on resource [http://maven2.corp.dig.com:8080/archiva/repository/internal//com/go/tea /tea/3.3.11/tea-3.3.11.pom]:Error transferring file at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transfer SimpleFile(DefaultRepositoryProxyConnectors.java:717) at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.transfer File(DefaultRepositoryProxyConnectors.java:542) at org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFro mProxies(DefaultRepositoryProxyConnectors.java:155) at org.apache.maven.archiva.web.repository.ProxiedDavServer.applyServerSide Relocation(ProxiedDavServer.java:447) at org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFro mProxies(ProxiedDavServer.java:354) at org.apache.maven.archiva.web.repository.ProxiedDavServer.process(Proxied DavServer.java:189) at org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet. service(MultiplexedWebDavServlet.java:119) at org.apache.maven.archiva.web.repository.RepositoryServlet.service(Reposi toryServlet.java:155) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web ApplicationHandler.java:830) at com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDisp atcher.java:189) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web ApplicationHandler.java:821) at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.j ava:39) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(Web ApplicationHandler.java:821) at com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(Action ContextCleanUp.java:88) at
RE: Proxy connectors fails to download, Archiva needs restart
FYI, I have noticed something similar after Archiva is up for a while and I thought it was related to my other consumer issues so I didn't mention it. One possibility to consider is the difference of Archiva being used as both a proxy and repository manager as opposed to just a proxy. Anyway, I thought I should let it be know that others are seeing this behavior as well. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 02, 2008 3:10 PM To: archiva-users@maven.apache.org Subject: Re: Proxy connectors fails to download, Archiva needs restart I commented in the JIRA issue - it'd be great if you could turn on debug level logging in log4j.xml to see what the exception is that causes this. Cheers, Brett On 03/04/2008, Jackson, Brian R [EMAIL PROTECTED] wrote: I'm experiencing the following issue. After the Archiva server has been up for some time, one of my proxy connectors starts to fail and the only solution is to restart the service. I see the following errors in the log: 76814726 [SocketListener0-0] WARN org.apache.maven.archiva.proxy.RepositoryProxyConnectors:default - Transfer error from repository wdig.releases for artifact com.go.trove:trove:1.5.4::pom, continuing to next repository. Error message: Download failure on resource The repository wdig.releases is another Archiva instance that we have internal to our company. The proxy connector is setup for a direct connection with no HTTP proxying. I know the network connection isn't an issue because a restart of just the Archiva service solves the problem temporarily. ___ Brian Jackson Sr. Software Engineer ESPN.com Fantasy Games (860) 766-2511 -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: archiva-1.0.2 eta?
Currently, I have the following enbled: * create-missing-checksums * index-content * repository-purge * repository-purge * validate-checksums -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:24 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Jason, I took a look at this - the only way I could reproduce it was by adding maven-metadata.xml to the list of artifacts in the repository scanning tab - can you confirm whether that is the case for you? Cheers, Brett On 14/03/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Here is a snippet from the log file: 431177909 [pool-2-thread-1] ERROR org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Consumer [repository-purge] had an error when processing file [/proxy/maven2/org/apache/cxf/cxf-rt-bindings-soap/2.0.3-incubator/maven -metadata.xml]: Invalid path to Artifact: filename format is invalid, -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: archiva-1.0.2 eta?
Here is my archiva.xml, in case it provides any other info. -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:33 PM To: archiva-users@maven.apache.org Subject: RE: archiva-1.0.2 eta? I was using the metdata-updater at one time, but we started to see stange issues with the buld number being reset when we do a deploy, even though the build number should have been 35, it became 1. I thought this consumer might be the cause. -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:29 PM To: archiva-users@maven.apache.org Subject: RE: archiva-1.0.2 eta? Currently, I have the following enbled: * create-missing-checksums * index-content * repository-purge * repository-purge * validate-checksums -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:24 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Jason, I took a look at this - the only way I could reproduce it was by adding maven-metadata.xml to the list of artifacts in the repository scanning tab - can you confirm whether that is the case for you? Cheers, Brett On 14/03/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Here is a snippet from the log file: 431177909 [pool-2-thread-1] ERROR org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Consumer [repository-purge] had an error when processing file [/proxy/maven2/org/apache/cxf/cxf-rt-bindings-soap/2.0.3-incubator/maven -metadata.xml]: Invalid path to Artifact: filename format is invalid, -- Brett Porter Blog: http://blogs.exist.com/bporter/ ?xml version=1.0 encoding=UTF-8? configuration version2/version repositoryScanning fileTypes fileType idartifacts/id patterns pattern**/*.bin/pattern pattern**/*.car/pattern pattern**/*.dtd/pattern pattern**/*.ear/pattern pattern**/*.jar/pattern pattern**/*.mar/pattern pattern**/*.nar/pattern pattern**/*.pom/pattern pattern**/*.rar/pattern pattern**/*.rpm/pattern pattern**/*.sar/pattern pattern**/*.tar.bz2/pattern pattern**/*.tar.gz/pattern pattern**/*.tld/pattern pattern**/*.war/pattern pattern**/*.xml/pattern pattern**/*.zip/pattern /patterns /fileType fileType idauto-remove/id patterns pattern**/*-/pattern pattern**/*.bak/pattern pattern**/*~/pattern /patterns /fileType fileType idignored/id patterns pattern**/*.rb/pattern pattern**/*.sh/pattern pattern**/.DAV/**/pattern pattern**/.htaccess/pattern pattern**/.svn/**/pattern pattern**/KEYS/pattern /patterns /fileType fileType idindexable-content/id patterns pattern**/*.block/pattern pattern**/*.config/pattern pattern**/*.dtd/pattern pattern**/*.pom/pattern pattern**/*.tld/pattern pattern**/*.txt/pattern pattern**/*.TXT/pattern pattern**/*.xml/pattern pattern**/*.xsd/pattern /patterns /fileType /fileTypes knownContentConsumers knownContentConsumercreate-missing-checksums/knownContentConsumer knownContentConsumerindex-content/knownContentConsumer knownContentConsumerrepository-purge/knownContentConsumer knownContentConsumerupdate-db-artifact/knownContentConsumer knownContentConsumervalidate-checksums/knownContentConsumer /knownContentConsumers invalidContentConsumers invalidContentConsumerupdate-db-bad-content/invalidContentConsumer /invalidContentConsumers /repositoryScanning databaseScanning cronExpression0 15 * * * ?/cronExpression unprocessedConsumers unprocessedConsumerindex-archive-toc/unprocessedConsumer unprocessedConsumerindex-artifact/unprocessedConsumer unprocessedConsumerindex-public-methods/unprocessedConsumer unprocessedConsumerupdate-db-bytecode-stats/unprocessedConsumer unprocessedConsumerupdate-db-project/unprocessedConsumer unprocessedConsumervalidate-repository-metadata/unprocessedConsumer /unprocessedConsumers cleanupConsumers cleanupConsumernot-present-remove-db-artifact/cleanupConsumer cleanupConsumernot-present-remove-db-project/cleanupConsumer cleanupConsumernot-present-remove-indexed/cleanupConsumer /cleanupConsumers /databaseScanning managedRepositories managedRepository location/disk1/html/maven2-client/location snapshotstrue/snapshots refreshCronExpression0 0 4 * * ?/refreshCronExpression daysOlder0/daysOlder
RE: archiva-1.0.2 eta?
I can probably change that to be more specific to only pick up the specific xml files. This might fix my build number issue as well. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 19, 2008 9:42 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? On 20/03/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I just sent my archiva.xml, which should give you a complete picture. Ok, so I will file a new issue, but removing *.xml from your artifacts list temporarily will fix the exception problems you were having with the latest code (since it's picking up metadata files). As for the wrong build numbers, you were probably seeing this: http://jira.codehaus.org/browse/MNG-3441 Cheers, Brett -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: archiva-1.0.2 eta?
I will send the log output later tonight. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2008 4:42 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? What is the error you are getting? I tried the one you previously posted to the list and it ran through the unit tests on the branch just fine. - Brett On 14/03/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I am using the SNAPSHOT that Brett provided, and MRM-691 seems to be fixed, but not MRM-632 as I am still seeing that for some artifacts. -Original Message- From: greyfairer1 [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2008 9:20 AM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? So, apart from the log file issues, are MR-632 and MRM-691 fixed in the 1.02-SNAPSHOT release? Or should I build archiva from trunk to check? Brett Porter wrote: Are these issues new, or were they present before (just wondering if it's a regression because of my changes). Anyway, I can add more tests. How is the performance/stability after a little while now? - Brett On 27/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Looks like I still have some issues. I have attached parts of the log file because the entire file is too large. Let me know if you would like any other information. I am using the same archiva.xml as before. These errors may be due to some non-standard artifacts in our repo, but most of them do seem correct to me. I do know that we have some artifacts that do not have poms though. -- View this message in context: http://www.nabble.com/archiva-1.0.2-eta--tp15643198p16030511.html Sent from the archiva-users mailing list archive at Nabble.com. -- Brett Porter Blog: http://blogs.exist.com/bporter/
archiva corrupts the snapshot repository so that deploys don't increment build number
It appears that archiva consumers modify the repository and change timestamps to GMT. The next time I try to deploy an artifact it starts over at build number 1, even though the previous build number was 30. I am not sure what I can do to resolve this either in Archvia or maven??
RE: archiva-1.0.2 eta?
Thanks Joakim. I already found it changed it locally. I also modified
the logging for the wrapper.conf.
I might suggest changing the default that ships OR at least providing
some good documentation around this issue and how to configure the
logging in both log4j.xml and the wrapper.conf.
-Original Message-
From: Joakim Erdfelt [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 10:50 PM
To: archiva-users@maven.apache.org
Subject: Re: archiva-1.0.2 eta?
Here's a changed log4j.xml file for you.
It changes from a DailyRollingFileAppender to a RollingFileAppender with
a max of Six 500MB files ever.
It also squelches the output to error / fatal messages only in the main
log.
It leaves the audit log alone.
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE log4j:configuration SYSTEM log4j.dtd
log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/;
appender name=rolling class=org.apache.log4j.RollingFileAppender
param name=file value=${appserver.base}/logs/archiva.log /
param name=append value=true /
param name=maxFileSize value=500MB /
param name=maxBackupIndex value=6 /
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%-4r [%t] %-5p %c %x -
%m%n/
/layout
/appender
appender name=auditlog
class=org.apache.log4j.DailyRollingFileAppender
param name=file value=${appserver.base}/logs/audit.log /
param name=append value=true /
param name=datePattern value='.'-MM-dd /
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d{-MM-dd HH:mm:ss}
%m%n/
/layout
/appender
appender name=console class=org.apache.log4j.ConsoleAppender
param name=Target value=System.out/
layout class=org.apache.log4j.PatternLayout
param name=ConversionPattern value=%d [%t] %-5p %c %x -
%m%n/
/layout
/appender
logger name=org.apache.archiva.AuditLog
level value=info /
appender-ref ref=auditlog /
/logger
root
priority value =error /
appender-ref ref=console /
appender-ref ref=rolling /
/root
/log4j:configuration
Brett Porter wrote:
On 27/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote:
I have not. Is that configured in the plexus.xml?
No, log4j.xml - but it seems like the problem is just too many
exception messages? Is that what is filling the log so fast?
- Brett
RE: archiva-1.0.2 eta?
I have not. Is that configured in the plexus.xml? -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 10:06 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? I see - have you customised the default logging levels? - Brett On 27/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: I think it has something to do with the log file reaching 2 GB in size. I couldn't even restart it until I remove the log files. -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 9:44 PM To: archiva-users@maven.apache.org Subject: RE: archiva-1.0.2 eta? The snapshot build crashed on my this evening and had to be stopped. When I stopped it, it had a stale pid and said it wasn't running. However, there was some process still running that I had to kill manually. Either way, there is still some type of issue. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 26, 2008 1:58 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Are these issues new, or were they present before (just wondering if it's a regression because of my changes). Anyway, I can add more tests. How is the performance/stability after a little while now? - Brett On 27/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Looks like I still have some issues. I have attached parts of the log file because the entire file is too large. Let me know if you would like any other information. I am using the same archiva.xml as before. These errors may be due to some non-standard artifacts in our repo, but most of them do seem correct to me. I do know that we have some artifacts that do not have poms though. -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: archiva-1.0.2 eta?
Will do. I will install it today and test if for a couple of days. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, February 25, 2008 7:53 AM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? If you are able to, please test the following build: http://people.apache.org/~brett/builds/apache-archiva-1.0.2-SNAPSHOT-bin .zip (please note this is not an official release) The problems should now be corrected. It would be helpful to check how that runs for a few days so we know whether it is worth putting together as a release including the fixes so far, or if more investigation is needed. Thanks, Brett On 25/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: Actually, I misspoke. I checked the logs again today and saw the NPE during the database scanning. I am not sure what is going on because I didn't change any of the database configuration from installed defaults. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 12:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Did you switch to a build of 1.0.2-SNAPSHOT which caused the issue to not become reproducible, or have you stopped observing it in your current installation? Thanks, Brett On 24/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: In particular, I would like the fixes for the following issues: * http://jira.codehaus.org/browse/MRM-674 * http://jira.codehaus.org/browse/MRM-632 * http://jira.codehaus.org/browse/MRM-691 Only the last one still needs to be fixed, if it is still an issue. I am not able to reproduce it anymore. -Original Message- From: Joakim Erdfelt [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 5:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Are there any specific bugs in the bug tracking system that you feel need attention? Archiva 1.0.2 tasked bugs - http://urltea.com/2rqi Archiva overall open (non-future) bugs - http://urltea.com/2rqj - Joakim Jason Chaffee wrote: Is there an ETA on the 1.0.2 release? I would really like to get a couple of bug fixes. -- Brett Porter Blog: http://blogs.exist.com/bporter/ -- Brett Porter Blog: http://blogs.exist.com/bporter/
RE: archiva-1.0.2 eta?
Actually, I misspoke. I checked the logs again today and saw the NPE during the database scanning. I am not sure what is going on because I didn't change any of the database configuration from installed defaults. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Sunday, February 24, 2008 12:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Did you switch to a build of 1.0.2-SNAPSHOT which caused the issue to not become reproducible, or have you stopped observing it in your current installation? Thanks, Brett On 24/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: In particular, I would like the fixes for the following issues: * http://jira.codehaus.org/browse/MRM-674 * http://jira.codehaus.org/browse/MRM-632 * http://jira.codehaus.org/browse/MRM-691 Only the last one still needs to be fixed, if it is still an issue. I am not able to reproduce it anymore. -Original Message- From: Joakim Erdfelt [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 5:31 PM To: archiva-users@maven.apache.org Subject: Re: archiva-1.0.2 eta? Are there any specific bugs in the bug tracking system that you feel need attention? Archiva 1.0.2 tasked bugs - http://urltea.com/2rqi Archiva overall open (non-future) bugs - http://urltea.com/2rqj - Joakim Jason Chaffee wrote: Is there an ETA on the 1.0.2 release? I would really like to get a couple of bug fixes. -- Brett Porter Blog: http://blogs.exist.com/bporter/
Archiva crashes after a couple of days
I am running the standalone archiva and I have about 4 managed repositories (including a proxy repo), and about 6 or 7 remote repositories. I create a single proxy connector to all of the remote repositories and changed my settings.xml to be a mirrorOf *. Currently, I only have my Continuous Integration box configured to use Archiva as a proxy and I am finding that it crashes every couple of days. Also, I am running all of default consumers and I do see the bug about invalid path for some artifacts (Bret Porter closed the bug yesterday and the fix will be in 1.0.2). Has anyone else seen this? Any ideas?
RE: Archiva crashes after a couple of days
I am running on RedHat Enterprise 4 update 4. It has crashed on m2 at least 6 times in the last two weeks and I am not doing anything special with it. Also, I have noticed that it is creating almost 5 Gigs in logs files a day. I wonder if this has anything to do with it. -Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 12:45 PM To: archiva-users@maven.apache.org Subject: Re: Archiva crashes after a couple of days Jason, I can tell you that we've had our Archiva instance up and running for at least 3+ weeks without having to restart. We have 5 repositories and about 6 remote repositories and we too are using the standalone product and nearly all consumers. What platform are you running on? Eric On Fri, 2008-02-22 at 12:40 -0800, Jason Chaffee wrote: I am running the standalone archiva and I have about 4 managed repositories (including a proxy repo), and about 6 or 7 remote repositories. I create a single proxy connector to all of the remote repositories and changed my settings.xml to be a mirrorOf *. Currently, I only have my Continuous Integration box configured to use Archiva as a proxy and I am finding that it crashes every couple of days. Also, I am running all of default consumers and I do see the bug about invalid path for some artifacts (Bret Porter closed the bug yesterday and the fix will be in 1.0.2). Has anyone else seen this? Any ideas?
RE: Archiva crashes after a couple of days
It sounds like the default cron expressions are the culprit then. I imagine it was tested on the amount of repos and with the amount of artifacts that a big company might have and thus it causes problems. Could you give me the cron expression that you are using for repo scans and database updates? Thanks. -Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 1:07 PM To: archiva-users@maven.apache.org Subject: RE: Archiva crashes after a couple of days I too had this same issue. Make sure your cron syntax is correct as it is not standard unix cron syntax. The first entry is a second number, not minutes. I initially (and accidentally) setup our cron jobs to run at a crazy pace, I think every second. I asked the mailing list if there was a way to clear these queue of events so I could let the app run its course, but received no answers. i eventually had to reinstall fresh to get around it but all works great now. FYI, we're on RHEL 4 update 4 as well. Eric On Fri, 2008-02-22 at 13:01 -0800, Jason Chaffee wrote: I am running on RedHat Enterprise 4 update 4. It has crashed on m2 at least 6 times in the last two weeks and I am not doing anything special with it. Also, I have noticed that it is creating almost 5 Gigs in logs files a day. I wonder if this has anything to do with it. -Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 12:45 PM To: archiva-users@maven.apache.org Subject: Re: Archiva crashes after a couple of days Jason, I can tell you that we've had our Archiva instance up and running for at least 3+ weeks without having to restart. We have 5 repositories and about 6 remote repositories and we too are using the standalone product and nearly all consumers. What platform are you running on? Eric On Fri, 2008-02-22 at 12:40 -0800, Jason Chaffee wrote: I am running the standalone archiva and I have about 4 managed repositories (including a proxy repo), and about 6 or 7 remote repositories. I create a single proxy connector to all of the remote repositories and changed my settings.xml to be a mirrorOf *. Currently, I only have my Continuous Integration box configured to use Archiva as a proxy and I am finding that it crashes every couple of days. Also, I am running all of default consumers and I do see the bug about invalid path for some artifacts (Bret Porter closed the bug yesterday and the fix will be in 1.0.2). Has anyone else seen this? Any ideas?
RE: Archiva crashes after a couple of days
My schedules were definitely wrong and causing scanning often. I think this is why it was crashing. -Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 1:38 PM To: archiva-users@maven.apache.org Subject: RE: Archiva crashes after a couple of days We use: 0 30 2 * * ? - daily at 2:30 am 0 30 * * * ? - every 30 mins The default out of the box shouldn't be an issue I wouldn't think. How large are your repos? Ours: 344Mjasper 332Kplugins 203Mproxied 107Mreleases 239Msnapshots On Fri, 2008-02-22 at 13:28 -0800, Jason Chaffee wrote: I am using the defaults, out of box expressions. So, it seems those too could be fine tuned. -Original Message- From: Brown, Carlton [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 1:14 PM To: archiva-users@maven.apache.org Subject: RE: Archiva crashes after a couple of days -Original Message- From: Eric Miles [mailto:[EMAIL PROTECTED] Sent: Friday, February 22, 2008 4:07 PM To: archiva-users@maven.apache.org Subject: RE: Archiva crashes after a couple of days I too had this same issue. Make sure your cron syntax is correct as it is not standard unix cron syntax. The first entry is a second number, not minutes. I initially (and accidentally) setup our cron jobs to run at a crazy pace, I think every second. Me three. I didn't see any reason not to scan every minute, but in fact it was every second. Result - massive log files, Archiva hung. Did not have to reinstall it, though. The cron setup would be a good candidate for improved input forms and/or validation. - This message contains PRIVILEGED and CONFIDENTIAL information that is intended only for use by the named recipient. If you are not the named recipient, any disclosure, dissemination, or action based on the contents of this message is prohibited. In such case please notify us and destroy and delete all copies of this transmission. Thank you.
RE: repository purge isn't working in 1.0.1
103617966 [pool-1-thread-1] INFO org.codehaus.plexus.taskqueue.execution.TaskExecutor:database-update - Executing task from queue with job name: database-job 103617966 [pool-1-thread-1] INFO org.codehaus.plexus.taskqueue.execution.TaskExecutor:database-update - Task: Updating unprocessed artifacts 103617966 [pool-2-thread-1] INFO org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning - Executing task from queue with job name: repository-job:internal 103617966 [Thread-6] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:repository-sca nning - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.NullPointerException at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(Futu reTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask .java:118) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: java.lang.NullPointerException at org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTa skExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:98) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter .call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask .java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) 103617967 [pool-2-thread-1] INFO org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning - Executing task from queue with job name: repository-job:snapshots 103617967 [Thread-6] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:repository-sca nning - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: java.lang.NullPointerException at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(Futu reTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask .java:118) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: java.lang.NullPointerException at org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTa skExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:98) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$Execut orRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter .call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask .java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker .run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:595) -Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 12:57 PM To: archiva-users@maven.apache.org Subject: RE: repository purge isn't working in 1.0.1 I have attached a snippet of the log. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, February 11, 2008 4:55 AM To: archiva-users@maven.apache.org Subject: Re: repository purge isn't working in 1.0.1 I think it would be essential to capture the stacktrace even if it isn't relevant so we can clear that up. Also, if you could post the failed task that you think needs more info and some context we can look at ways to troubleshoot and improve the logging in the future. - Brett On 11/02/2008, Jason Chaffee [EMAIL PROTECTED] wrote: For some reason, the repository purge hasn't been working for me. I configured the date to be 0 and the purge count to be 10, yet after running for 3 days there are still some snapshots with over 50 artifacts. I did see the log said something about the a failed task for repository-job:snapshots, but there wasn't much info. Also, there was a stacktrace with something from java.util.concurrent, but the message and details are less than helpful. Anyone have any ideas? -- Brett Porter Blog
