You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Seva Popov <se...@tvworks.com> on 2008/06/12 23:33:42 UTC
Metadata-updater consumer is not get triggered after manual deletion of some artifacts and/or metadata from the repository
Hi,
We are using Archiva 1.0.2 running in Tomcat 5.5.9 and we have an issue
with the metadata-updater consumer not getting triggered during the
repository scan that we execute after we manually delete some artifacts
and/or metadata from the repository's file system.
Below is from the archiva.log after we've changed INFO level to DEBUG in
the log4j.xml configuration:
1752315 [http-8080-3] INFO
com.opensymphony.xwork.Action:schedulerAction - [ActionMessage] Your
request to have repository [tva.snapshot] be indexed has been queued.
1752315 [pool-2-thread-1] INFO
org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning
- Executing task from queue with job name: repository-job:tva.snapshot
1752327 [pool-2-thread-1] INFO
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Walk Started: [tva.snapshot] /disk1/html/maven2-snapshot
1830359 [pool-2-thread-1] DEBUG
org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metada
ta-updater - Skipping uptodate metadata:
com/tvworks/tva/mpeg/1.1.0-SNAPSHOT/maven-metadata.xml
1830360 [pool-2-thread-1] DEBUG
org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metada
ta-updater - Skipping uptodate metadata:
com/tvworks/tva/mpeg/maven-metadata.xml
1833308 [pool-2-thread-1] DEBUG
org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metada
ta-updater - Skipping uptodate metadata:
com/tvworks/tva/cpp/3.4.0-SNAPSHOT/maven-metadata.xml
1833309 [pool-2-thread-1] DEBUG
org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metada
ta-updater - Skipping uptodate metadata:
com/tvworks/tva/cpp/maven-metadata.xml
1837469 [pool-2-thread-1] INFO
org.apache.maven.archiva.repository.scanner.RepositoryScanner:default -
Walk Finished: [tva.snapshot] /disk1/html/maven2-snapshot
1837469 [pool-2-thread-1] INFO
org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning
- Finished repository task:
.\ Scan of tva.snapshot \.__________________________________________
Repository Dir : /disk1/html/maven2-snapshot
Repository Name : TVA Snapshot Repository
Repository Layout : default
Known Consumers : (8 configured)
update-db-artifact
repository-purge
auto-rename
index-content
validate-checksums
auto-remove
metadata-updater
create-missing-checksums
Invalid Consumers : <none>
Duration : 1 Minute 25 Seconds 142 Milliseconds
When Gathered : 6/12/08 12:39 PM
Total File Count : 49772
Avg Time Per File : 1 Millisecond
______________________________________________________________
As you can see above, the metadata-updater consumer did get triggered
for some of the projects. But it wasn't triggered for the "proxylogger"
project where we manually logged into the box and deleted some
artifacts.
Below is how our repository file system looks:
[spopov@maven tva]$ pwd
/var/www/html/maven2-snapshot/com/tvworks/tva
[spopov@maven tva]$ ll
total 148
drwxr-xr-x 3 maven maven 4096 Nov 25 2007 adminmanager
drwxr-xr-x 16 maven maven 4096 Jun 6 01:49 apps
drwxr-xr-x 13 maven maven 4096 Jun 6 12:08 backendapps
drwxr-xr-x 7 maven maven 4096 Apr 7 16:22 comcast
drwxr-xr-x 36 maven maven 4096 Aug 24 2007 common
drwxr-xr-x 3 maven maven 4096 Mar 28 13:54 core
drwxr-xr-x 5 maven maven 4096 Nov 30 2007 cox
drwxr-xr-x 4 maven maven 4096 Jun 4 13:14 cpp
drwxr-xr-x 3 maven maven 4096 Mar 26 18:01 G4
drwxr-xr-x 7 maven maven 4096 Aug 17 2007 installs
drwxr-xr-x 5 maven maven 4096 Jun 4 13:14 java
drwxr-xr-x 28 maven maven 4096 May 28 11:56 mac
drwxr-xr-x 17 maven maven 4096 Feb 28 12:06 mac-settings
drwxr-xr-x 6 maven maven 4096 May 7 22:25 maven
-rw-r--r-- 1 maven maven 492 Apr 22 2007 maven-metadata.xml
-rw-r--r-- 1 maven maven 32 Apr 22 2007 maven-metadata.xml.md5
-rw-r--r-- 1 maven maven 40 Apr 22 2007 maven-metadata.xml.sha1
drwxr-xr-x 4 maven maven 4096 Jan 25 14:44 maxdevtools
drwxr-xr-x 12 maven maven 4096 Aug 17 2007 media
drwxr-xr-x 33 maven maven 4096 May 28 11:46 messaging
drwxr-xr-x 16 maven maven 4096 Jun 11 10:20 mpeg
drwxr-xr-x 18 maven maven 4096 May 28 12:49 mss
drwxr-xr-x 65 maven maven 4096 Jun 5 15:57 packager
drwxr-xr-x 4 maven maven 4096 May 28 10:26 packaging
drwxr-xr-x 3 maven maven 4096 Jun 4 13:14 poms
drwxr-xr-x 9 maven maven 4096 Jun 2 13:29 proxylogger
drwxr-xr-x 4 maven maven 4096 Nov 25 2007 server
drwxr-xr-x 3 maven maven 4096 Nov 15 2006 si
drwxr-xr-x 3 maven maven 4096 Jun 4 13:14 super-tva
drwxr-xr-x 3 maven maven 4096 May 8 11:55 test
drwxr-xr-x 7 maven maven 4096 Dec 3 2007 tools
drwxr-xr-x 25 maven maven 4096 May 28 11:59 transport
drwxr-xr-x 7 maven maven 4096 Jun 4 13:14 tva
drwxr-xr-x 5 maven maven 4096 Mar 6 22:27 tva-org
drwxr-xr-x 19 maven maven 4096 May 28 11:44 twoway
drwxr-xr-x 6 maven maven 4096 Jun 5 11:29 usermanager
drwxr-xr-x 3 maven maven 4096 Dec 3 2007 wctree
Now, if we drill down into one of the "proxylogger" project's module we
can see:
[spopov@maven 1.2.0-SNAPSHOT]$ pwd
/var/www/html/maven2-snapshot/com/tvworks/tva/proxylogger/proxylogger-we
bapp/1.2.0-SNAPSHOT
[spopov@maven 1.2.0-SNAPSHOT]$ ll
total 1756
-rw-r--r-- 1 maven maven 379 Jun 12 11:51 maven-metadata.xml
-rw-r--r-- 1 maven maven 32 Jun 12 11:51 maven-metadata.xml.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:51 maven-metadata.xml.sha1
-rw-r--r-- 1 maven maven 5268 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-exception-messages.xml
-rw-r--r-- 1 maven maven 32 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-exception-messages.xml.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-exception-messages.xml.sha1
-rw-r--r-- 1 maven maven 1090 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-license.xml
-rw-r--r-- 1 maven maven 32 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-license.xml.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-license.xml.sha1
-rw-r--r-- 1 maven maven 22381 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-log-messages.xml
-rw-r--r-- 1 maven maven 32 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-log-messages.xml.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-log-messages.xml.sha1
-rw-r--r-- 1 maven maven 3380 Jun 12 11:34
proxylogger-webapp-1.2.0-20080612.183457-1.pom
-rw-r--r-- 1 maven maven 32 Jun 12 11:34
proxylogger-webapp-1.2.0-20080612.183457-1.pom.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1.pom.sha1
-rw-r--r-- 1 maven maven 15929 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-sources.jar
-rw-r--r-- 1 maven maven 32 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-sources.jar.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-sources.jar.sha1
-rw-r--r-- 1 maven maven 6321 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-test-sources.jar
-rw-r--r-- 1 maven maven 32 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-test-sources.jar.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:35
proxylogger-webapp-1.2.0-20080612.183457-1-test-sources.jar.sha1
-rw-r--r-- 1 maven maven 1656399 Jun 12 11:34
proxylogger-webapp-1.2.0-20080612.183457-1.war
-rw-r--r-- 1 maven maven 32 Jun 12 11:34
proxylogger-webapp-1.2.0-20080612.183457-1.war.md5
-rw-r--r-- 1 maven maven 40 Jun 12 11:34
proxylogger-webapp-1.2.0-20080612.183457-1.war.sha1
And if we open up the maven-metadata.xml it contains the stale maven
metadata (that we've expected should have been updated by the
metadata-updater consumer during the scan) after we manually removed all
the artifacts with the build #2 that were built on 20080612.185123:
[spopov@maven 1.2.0-SNAPSHOT]$ cat maven-metadata.xml
<?xml version="1.0" encoding="UTF-8"?><metadata>
<groupId>com.tvworks.tva.proxylogger</groupId>
<artifactId>proxylogger-webapp</artifactId>
<version>1.2.0-SNAPSHOT</version>
<versioning>
<snapshot>
<timestamp>20080612.185123</timestamp>
<buildNumber>2</buildNumber>
</snapshot>
<lastUpdated>20080612185147</lastUpdated>
</versioning>
The issue is reproducible. But the strange thing is that sometimes (very
rarely) the metadata-updater consumer does get triggered for the
manually modified file system and it correctly fixed the metadata.
However, we were not able to see any difference in the taken steps to
see what should make the difference.
Please, let me know whether this is a bug or am I missing something.
Thanks,
Seva