issues@archiva.apache.org Archives

[jira] Commented: (MRM-1293) migrate repository statistics to the metadata content repository

2009-12-08T11:33:55Z


    [ http://jira.codehaus.org/browse/MRM-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201725#action_201725
] 

Brett Porter commented on MRM-1293:
-----------------------------------

the main portion of work is now done. However, it is not currently doing the total artifact
counts that were done from the database. This needs to be revisited before closing the issue

> migrate repository statistics to the metadata content repository
> ----------------------------------------------------------------
>
>                 Key: MRM-1293
>                 URL: http://jira.codehaus.org/browse/MRM-1293
>             Project: Archiva
>          Issue Type: Improvement
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> currently, after every scan, repository statistics are persisted to the database. These
could easily be stored in the metadata repository. While at present we will keep the "per-scan"
approach, in the future this might better be represented as a regularly stored snapshot /
built in versioning of the metadata. It could potentially be adding this information on the
fly instead of at scan by adding a callback in the repository API when an artifact / project
is created - however this will be approached later.
> When migrating the functionality, it should be offered as a standalone plugin (the only
dependencies should be in the webapp that need to render the information and trigger some
cleanup).
> The following changes will be needed:
> - save the statistics in ArchivaRepositoryScanningTaskExecutor / ArchivaRepositoryScanningTaskExecutorTest
> - reset statistics in EditManagedRepositoryAction / EditManagedRepositoryActionTest when
location changes
> - query for a prior successful scan in RepositoryArchivaTaskScheduler
> - retrieve last scan info in RepositoryAction and update corresponding JSP to display
information correctly
> - generate report action to query scan statistics between given dates and aggregate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1185) Archiva Reporting Modification Request

2009-12-08T06:27:55Z


     [ http://jira.codehaus.org/browse/MRM-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jevica Arianne B. Zurbano updated MRM-1185:
-------------------------------------------

    Description: 
# Log onto Archiva server as "admin".
# Click "Reports" in left nav.
# Select a repository.
# Click "View Statistics"

The resulting report contains several counts including "jar" and "war" files.

We would like the report to include the following types:

EARs
DLLs
EXEs
ZIPs

All of these except ZIPs appear to be readily available in the

"org.apache.maven.archiva.reporting.RepositioryStatistics"

type which appears to be used to create the report.

It appears that EARs, DLLs, and EXEs can added to the report with a simple change to the

"org.apache.maven.archiva.web.action.reports.GenerateReportAction"

type.

If the above analysis is correct, we would ask that this be delivered in 2 parts:

1. Add EARs , DLLs, and EXEs to the report created by "GenerateReportAction" since this can
be easily turned around.
2. Add ZIPs as soon as reasonably able to do so.

  was:
Log onto a Maestro/Archiva server as "admin".
Click Artifact Repository in top-nav.
Click "Reports" in left nav.
Select a repository.
Click "View Statistics"

The resulting report contains several counts including "jar" and "war" files.

We would like the report to include the following types:

EARs
DLLs
EXEs
ZIPs

All of these except ZIPs appear to be readily available in the

"org.apache.maven.archiva.reporting.RepositioryStatistics"

type which appears to be used to create the report.

It appears that EARs, DLLs, and EXEs can added to the report with a simple change to the

"org.apache.maven.archiva.web.action.reports.GenerateReportAction"

type.

If the above analysis is correct, we would ask that this be delivered in 2 parts:

1. Add EARs , DLLs, and EXEs to the report created by "GenerateReportAction" since this can
be easily turned around.
2. Add ZIPs as soon as reasonably able to do so.


> Archiva Reporting Modification Request
> --------------------------------------
>
>                 Key: MRM-1185
>                 URL: http://jira.codehaus.org/browse/MRM-1185
>             Project: Archiva
>          Issue Type: New Feature
>            Reporter: harry arbasa
>            Priority: Minor
>             Fix For: 1.3
>
>
> # Log onto Archiva server as "admin".
> # Click "Reports" in left nav.
> # Select a repository.
> # Click "View Statistics"
> The resulting report contains several counts including "jar" and "war" files.
> We would like the report to include the following types:
> EARs
> DLLs
> EXEs
> ZIPs
> All of these except ZIPs appear to be readily available in the
> "org.apache.maven.archiva.reporting.RepositioryStatistics"
> type which appears to be used to create the report.
> It appears that EARs, DLLs, and EXEs can added to the report with a simple change to
the
> "org.apache.maven.archiva.web.action.reports.GenerateReportAction"
> type.
> If the above analysis is correct, we would ask that this be delivered in 2 parts:
> 1. Add EARs , DLLs, and EXEs to the report created by "GenerateReportAction" since this
can be easily turned around.
> 2. Add ZIPs as soon as reasonably able to do so.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1293) migrate repository statistics to the metadata content repository

2009-12-07T23:27:55Z


    [ http://jira.codehaus.org/browse/MRM-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201632#action_201632
] 

Brett Porter commented on MRM-1293:
-----------------------------------

have started to commit this implementation to the MRM-1025 branch. Currently only the last
bullet point remains to be implemented, as well as to re-add the storage of extended statistics
(artifact counts), then to clean up the old beans.

> migrate repository statistics to the metadata content repository
> ----------------------------------------------------------------
>
>                 Key: MRM-1293
>                 URL: http://jira.codehaus.org/browse/MRM-1293
>             Project: Archiva
>          Issue Type: Improvement
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> currently, after every scan, repository statistics are persisted to the database. These
could easily be stored in the metadata repository. While at present we will keep the "per-scan"
approach, in the future this might better be represented as a regularly stored snapshot /
built in versioning of the metadata. It could potentially be adding this information on the
fly instead of at scan by adding a callback in the repository API when an artifact / project
is created - however this will be approached later.
> When migrating the functionality, it should be offered as a standalone plugin (the only
dependencies should be in the webapp that need to render the information and trigger some
cleanup).
> The following changes will be needed:
> - save the statistics in ArchivaRepositoryScanningTaskExecutor / ArchivaRepositoryScanningTaskExecutorTest
> - reset statistics in EditManagedRepositoryAction / EditManagedRepositoryActionTest when
location changes
> - query for a prior successful scan in RepositoryArchivaTaskScheduler
> - retrieve last scan info in RepositoryAction and update corresponding JSP to display
information correctly
> - generate report action to query scan statistics between given dates and aggregate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-815) aggregate indices for repository groups

2009-12-07T17:02:55Z


    [ http://jira.codehaus.org/browse/MRM-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201582#action_201582
] 

Jeremie BOUSQUET commented on MRM-815:
--------------------------------------

I think this might be relevant now in 1.2.2 as indexes are downloadable.
Typical use-case is using m2eclipse, with maven configured on a repository group in Archiva.
In this case indexes are incomplete, and search is very limited.

> aggregate indices for repository groups
> ---------------------------------------
>
>                 Key: MRM-815
>                 URL: http://jira.codehaus.org/browse/MRM-815
>             Project: Archiva
>          Issue Type: New Feature
>          Components: indexing
>    Affects Versions: 1.1
>            Reporter: Brett Porter
>             Fix For: Backlog
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1291) Archiva has periodic load-peaks

2009-12-07T12:15:55Z


    [ http://jira.codehaus.org/browse/MRM-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201533#action_201533
] 

Marc Lustig commented on MRM-1291:
----------------------------------

According to Brett everything will be solved in 1.2.3
Looking forward to test the release version....

> Archiva has periodic load-peaks 
> --------------------------------
>
>                 Key: MRM-1291
>                 URL: http://jira.codehaus.org/browse/MRM-1291
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.2.2
>         Environment: RHEL4, Oracle RDBMS
>            Reporter: Marc Lustig
>         Attachments: cpu-day.png, cpu-week2.png, screenshot-1.jpg
>
>
> Archiva causes periodically an increased system-load. (see Munin-stats attached)
> During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.
> I could not identify corresponding messages in the logs.
> Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1296) Audit logging report

2009-12-07T06:25:55Z

Audit logging report
--------------------

                 Key: MRM-1296
                 URL: http://jira.codehaus.org/browse/MRM-1296
             Project: Archiva
          Issue Type: New Feature
          Components: reporting, web application
            Reporter: Maria Odea Ching




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1295) repository identifier accepts spaces causing Error 404 when accessing the URL

2009-12-04T11:09:55Z

repository identifier accepts spaces causing Error 404 when accessing the URL
-----------------------------------------------------------------------------

                 Key: MRM-1295
                 URL: http://jira.codehaus.org/browse/MRM-1295
             Project: Archiva
          Issue Type: Bug
    Affects Versions: 1.2.2
            Reporter: Jevica Arianne B. Zurbano


Steps to replicate:
# go to "Repositories" page
# add a repository with "identifier" containing spaces such as "internal ", " internal", "
internal ", "internal repo"
# click the URL of the added repository

This will result to 
{noformat}
HTTP ERROR 404

Problem accessing /archiva/repository/internal%20/. Reason:

    Invalid repository: internal%20
{noformat}


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1291) Archiva has periodic load-peaks

2009-12-04T09:23:55Z


     [ http://jira.codehaus.org/browse/MRM-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marc Lustig updated MRM-1291:
-----------------------------

    Attachment: cpu-week2.png

I want to provide you a third chart.
The filled area shows the "blown-up" load on the left half.
The second half shows the normal load.
All seems to be caused by the periodic scan processes.


> Archiva has periodic load-peaks 
> --------------------------------
>
>                 Key: MRM-1291
>                 URL: http://jira.codehaus.org/browse/MRM-1291
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.2.2
>         Environment: RHEL4, Oracle RDBMS
>            Reporter: Marc Lustig
>         Attachments: cpu-day.png, cpu-week2.png, screenshot-1.jpg
>
>
> Archiva causes periodically an increased system-load. (see Munin-stats attached)
> During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.
> I could not identify corresponding messages in the logs.
> Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MRM-1291) Archiva has periodic load-peaks

2009-12-04T09:23:55Z


    [ http://jira.codehaus.org/browse/MRM-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200559#action_200559
] 

Marc Lustig edited comment on MRM-1291 at 12/4/09 3:23 AM:
-----------------------------------------------------------

I want to provide you a third chart (cpu-week2.png).
The filled area shows the "blown-up" load on the left half.
The second half shows the normal load.
All seems to be caused by the periodic scan processes.


      was (Author: axismundi):
    I want to provide you a third chart.
The filled area shows the "blown-up" load on the left half.
The second half shows the normal load.
All seems to be caused by the periodic scan processes.

  
> Archiva has periodic load-peaks 
> --------------------------------
>
>                 Key: MRM-1291
>                 URL: http://jira.codehaus.org/browse/MRM-1291
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.2.2
>         Environment: RHEL4, Oracle RDBMS
>            Reporter: Marc Lustig
>         Attachments: cpu-day.png, cpu-week2.png, screenshot-1.jpg
>
>
> Archiva causes periodically an increased system-load. (see Munin-stats attached)
> During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.
> I could not identify corresponding messages in the logs.
> Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MRM-1241) Selenium Tests for Repository Scanning and Database

2009-12-04T07:07:55Z


     [ http://jira.codehaus.org/browse/MRM-1241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marecor Baclay closed MRM-1241.
-------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 1.3)
                   1.2.3

fixed at r.887086

> Selenium Tests for Repository Scanning and Database
> ---------------------------------------------------
>
>                 Key: MRM-1241
>                 URL: http://jira.codehaus.org/browse/MRM-1241
>             Project: Archiva
>          Issue Type: Test
>          Components: web application
>    Affects Versions: 1.2.2
>            Reporter: Marecor Baclay
>            Assignee: Marecor Baclay
>             Fix For: 1.2.3
>
>
> Add tests for Repository Scanning and Database

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MRM-1294) repository scan period is incorrect

2009-12-04T01:46:55Z


     [ http://jira.codehaus.org/browse/MRM-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter closed MRM-1294.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 1.2.3
         Assignee: Brett Porter

original bug fixed in r887027.

in r887030, the behaviour was further changed to use the start of the previous scan instead
of the end, so that artifacts added in the middle will be scanned. If they happen to have
been scanned before, they will be rescanned. This should not cause any issues - however if
it does, it might be beneficial to ignore them in the first scan and pick them up in the subsequent
one instead for reliability.

> repository scan period is incorrect
> -----------------------------------
>
>                 Key: MRM-1294
>                 URL: http://jira.codehaus.org/browse/MRM-1294
>             Project: Archiva
>          Issue Type: Bug
>          Components: repository scanning
>    Affects Versions: 1.2.2
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.2.3
>
>
> the repository scanner uses the end time of the previous scan + the duration as the start
time for the next scan. This means that any artifacts that are added in that time between
scans will not be detected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1294) repository scan period is incorrect

2009-12-04T01:22:55Z

repository scan period is incorrect
-----------------------------------

                 Key: MRM-1294
                 URL: http://jira.codehaus.org/browse/MRM-1294
             Project: Archiva
          Issue Type: Bug
          Components: repository scanning
    Affects Versions: 1.2.2
            Reporter: Brett Porter


the repository scanner uses the end time of the previous scan + the duration as the start
time for the next scan. This means that any artifacts that are added in that time between
scans will not be detected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1279) Calendar incorrect

2009-12-03T22:52:55Z


    [ http://jira.codehaus.org/browse/MRM-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200522#action_200522
] 

Brett Porter commented on MRM-1279:
-----------------------------------

what timezone are you in? Perhaps the calendar widget is using a fixed timezone.

> Calendar incorrect
> ------------------
>
>                 Key: MRM-1279
>                 URL: http://jira.codehaus.org/browse/MRM-1279
>             Project: Archiva
>          Issue Type: Bug
>          Components: reporting
>    Affects Versions: 1.2.2
>         Environment: Windows
>            Reporter: Raj Menattamai
>            Priority: Minor
>         Attachments: archiva_calendar_error.doc
>
>
> In Report menu, when the "start date" field is clicked, a calendar opens but it is incorrect.
For example, today is Tue, 11/17/2009. But in the calender it is 11/16/2009. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1291) Archiva has periodic load-peaks

2009-12-03T22:48:55Z


    [ http://jira.codehaus.org/browse/MRM-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200521#action_200521
] 

Brett Porter commented on MRM-1291:
-----------------------------------

did you have any large change in artifacts / rebuild the index in that period?

I'd like to encourage you to try 1.2.3-SNAPSHOT or the release - the hourly peaks will certainly
be reduced. If it seems managable, we can close this out.

> Archiva has periodic load-peaks 
> --------------------------------
>
>                 Key: MRM-1291
>                 URL: http://jira.codehaus.org/browse/MRM-1291
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.2.2
>         Environment: RHEL4, Oracle RDBMS
>            Reporter: Marc Lustig
>         Attachments: cpu-day.png, screenshot-1.jpg
>
>
> Archiva causes periodically an increased system-load. (see Munin-stats attached)
> During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.
> I could not identify corresponding messages in the logs.
> Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1293) migrate repository statistics to the metadata content repository

2009-12-03T22:48:55Z


     [ http://jira.codehaus.org/browse/MRM-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter updated MRM-1293:
------------------------------

    Fix Version/s: 1.3

> migrate repository statistics to the metadata content repository
> ----------------------------------------------------------------
>
>                 Key: MRM-1293
>                 URL: http://jira.codehaus.org/browse/MRM-1293
>             Project: Archiva
>          Issue Type: Improvement
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> currently, after every scan, repository statistics are persisted to the database. These
could easily be stored in the metadata repository. While at present we will keep the "per-scan"
approach, in the future this might better be represented as a regularly stored snapshot /
built in versioning of the metadata. It could potentially be adding this information on the
fly instead of at scan by adding a callback in the repository API when an artifact / project
is created - however this will be approached later.
> When migrating the functionality, it should be offered as a standalone plugin (the only
dependencies should be in the webapp that need to render the information and trigger some
cleanup).
> The following changes will be needed:
> - save the statistics in ArchivaRepositoryScanningTaskExecutor / ArchivaRepositoryScanningTaskExecutorTest
> - reset statistics in EditManagedRepositoryAction / EditManagedRepositoryActionTest when
location changes
> - query for a prior successful scan in RepositoryArchivaTaskScheduler
> - retrieve last scan info in RepositoryAction and update corresponding JSP to display
information correctly
> - generate report action to query scan statistics between given dates and aggregate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1280) SNAPSHOT artifacts are not processed with timestamped versions when added via web upload form while their poms are processed with timestamped versions resulting to being treated as separate versions in browse

2009-12-03T22:42:55Z


     [ http://jira.codehaus.org/browse/MRM-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter updated MRM-1280:
------------------------------

    Fix Version/s: 1.3

will check to see if this is solved by the refactoring in MRM-1025

> SNAPSHOT artifacts are not processed with timestamped versions when added via web upload
form while their poms are processed with timestamped versions resulting to being treated as
separate versions in browse
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MRM-1280
>                 URL: http://jira.codehaus.org/browse/MRM-1280
>             Project: Archiva
>          Issue Type: Bug
>          Components: browser, web application
>            Reporter: Maria Odea Ching
>             Fix For: 1.3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (MRM-1272) Empty Lucene Index

2009-12-03T22:40:55Z


     [ http://jira.codehaus.org/browse/MRM-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter closed MRM-1272.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 1.2.3
         Assignee: Brett Porter

I've added extra logging for the cause of the error. While thids may not fix the error, it
should reveal the problem if it occurs again.

> Empty Lucene Index
> ------------------
>
>                 Key: MRM-1272
>                 URL: http://jira.codehaus.org/browse/MRM-1272
>             Project: Archiva
>          Issue Type: Bug
>    Affects Versions: 1.2.2
>         Environment: centos 5.4, 64-bit, JRE 1.6.0_07-b06
>            Reporter: Andreas Baumann
>            Assignee: Brett Porter
>             Fix For: 1.2.3
>
>
> The Lucene Index contains the following:
> --- Lucene index dump ---
> Global Information:
> ===================
> 	number of documents: 1
> 	total number of features: 1
> 	total number of tokens: 1
> 	version: 1256287481733
> 	still current: true
> 	maximal document number: 1
> 	has deletions: false
> Field Information:
> ==================
> Fields of type 'ALL':
> 	DESCRIPTOR
> 	IDXINFO
> Fields of type 'INDEXED':
> 	DESCRIPTOR
> Fields of type 'INDEXED_NO_TERMVECTOR':
> 	DESCRIPTOR
> Fields of type 'INDEXED_WITH_TERMVECTOR':
> Fields of type 'TERMVECTOR':
> Fields of type 'TERMVECTOR_WITH_OFFSET':
> Fields of type 'TERMVECTOR_WITH_POSITION':
> Fields of type 'TERMVECTOR_WITH_POSITION_OFFSET':
> Fields of type 'UNINDEXED':
> 	IDXINFO
> Terms:
> ======
> DESCRIPTOR	NexusIndex	1
> --- End of Lucene index dump ---
> In the archiva.log I see:
> org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error occurred while
executing indexing task 'indexi
> ng-job:internal:stax-utils-20040917.pom:add'
>         at org.apache.maven.archiva.scheduled.executors.ArchivaIndexingTaskExecutor.executeTask(ArchivaIndexingTaskE
> xecutor.java:163)
>         at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueu
> eExecutor.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.runWorker(ThreadPoolExecutor.java:987)
>         at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
>         at java.lang.Thread.run(Unknown Source)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1293) migrate repository statistics to the metadata content repository

2009-12-02T13:27:55Z

migrate repository statistics to the metadata content repository
----------------------------------------------------------------

                 Key: MRM-1293
                 URL: http://jira.codehaus.org/browse/MRM-1293
             Project: Archiva
          Issue Type: Improvement
            Reporter: Brett Porter


currently, after every scan, repository statistics are persisted to the database. These could
easily be stored in the metadata repository. While at present we will keep the "per-scan"
approach, in the future this might better be represented as a regularly stored snapshot /
built in versioning of the metadata. It could potentially be adding this information on the
fly instead of at scan by adding a callback in the repository API when an artifact / project
is created - however this will be approached later.

When migrating the functionality, it should be offered as a standalone plugin (the only dependencies
should be in the webapp that need to render the information and trigger some cleanup).

The following changes will be needed:
- save the statistics in ArchivaRepositoryScanningTaskExecutor / ArchivaRepositoryScanningTaskExecutorTest
- reset statistics in EditManagedRepositoryAction / EditManagedRepositoryActionTest when location
changes
- query for a prior successful scan in RepositoryArchivaTaskScheduler
- retrieve last scan info in RepositoryAction and update corresponding JSP to display information
correctly
- generate report action to query scan statistics between given dates and aggregate


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (MRM-1293) migrate repository statistics to the metadata content repository

2009-12-02T13:27:55Z


     [ http://jira.codehaus.org/browse/MRM-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter reassigned MRM-1293:
---------------------------------

    Assignee: Brett Porter

> migrate repository statistics to the metadata content repository
> ----------------------------------------------------------------
>
>                 Key: MRM-1293
>                 URL: http://jira.codehaus.org/browse/MRM-1293
>             Project: Archiva
>          Issue Type: Improvement
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>
> currently, after every scan, repository statistics are persisted to the database. These
could easily be stored in the metadata repository. While at present we will keep the "per-scan"
approach, in the future this might better be represented as a regularly stored snapshot /
built in versioning of the metadata. It could potentially be adding this information on the
fly instead of at scan by adding a callback in the repository API when an artifact / project
is created - however this will be approached later.
> When migrating the functionality, it should be offered as a standalone plugin (the only
dependencies should be in the webapp that need to render the information and trigger some
cleanup).
> The following changes will be needed:
> - save the statistics in ArchivaRepositoryScanningTaskExecutor / ArchivaRepositoryScanningTaskExecutorTest
> - reset statistics in EditManagedRepositoryAction / EditManagedRepositoryActionTest when
location changes
> - query for a prior successful scan in RepositoryArchivaTaskScheduler
> - retrieve last scan info in RepositoryAction and update corresponding JSP to display
information correctly
> - generate report action to query scan statistics between given dates and aggregate

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1025) make the archiva database an optional part of the installation

2009-12-02T11:21:55Z


    [ http://jira.codehaus.org/browse/MRM-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200254#action_200254
] 

Brett Porter commented on MRM-1025:
-----------------------------------

the above has now been done. Along the way, several bugs have been fixed (usedBy and dependency
tree now work more reliably and quickly) and some tests added.

While it works, the code is not production ready - it litters the home directory with property
files and needs to be centralised. There is more testing to be added and there are probably
some edge cases that remain problematic. In particular, Maven-1 formatted storage repositories
is likely to not work.

Before moving to polishing, I'll continue proving the API by moving other archiva-database
uses over to it, such as RSS, reporting, and any remaining bits of the webapp and XMLRPC.





> make the archiva database an optional part of the installation
> --------------------------------------------------------------
>
>                 Key: MRM-1025
>                 URL: http://jira.codehaus.org/browse/MRM-1025
>             Project: Archiva
>          Issue Type: Task
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MRM-1291) Archiva has periodic load-peaks

2009-12-02T08:43:55Z


    [ http://jira.codehaus.org/browse/MRM-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200153#action_200153
] 

Marc Lustig edited comment on MRM-1291 at 12/2/09 2:43 AM:
-----------------------------------------------------------


I forgot to mention that this "periodic peaks" load-pattern occurs only from time to time.
I. e. when the pattern happens, the peaks occur periodically. But after restarting Archiva,
the pattern does not occur anymore for a couple of days or weeks.

I can be sure about this because we have notifiers installed that warn when a certain HTTP-request
on Archiva exceeds a certain threshold value.
We have not seen alarms between 3rd of november and 30th of november.
On the 30th out of a sudden the periodic load raised tremendously.

I doubt the RDBMS being slower could have an impact on the load.



      was (Author: axismundi):
    This pretty much sounds like a reasonable explanation - unfortunately it may not be the
(only) reason.

I forgot to mention that this "periodic peaks" load-pattern occurs only from time to time.
I. e. when the pattern happens, the peaks occur periodically. But after restarting Archiva,
the pattern does not occur anymore for a couple of days or weeks.

I can be sure about this because we have notifiers installed that warn when a certain HTTP-request
on Archiva exceeds a certain threshold value.
We have not seen alarms between 3rd of november and 30th of november.
On the 30th out of a sudden the periodic load raised tremendously.

I doubt the RDBMS being slower could have an impact on the load.


  
> Archiva has periodic load-peaks 
> --------------------------------
>
>                 Key: MRM-1291
>                 URL: http://jira.codehaus.org/browse/MRM-1291
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.2.2
>         Environment: RHEL4, Oracle RDBMS
>            Reporter: Marc Lustig
>         Attachments: cpu-day.png, screenshot-1.jpg
>
>
> Archiva causes periodically an increased system-load. (see Munin-stats attached)
> During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.
> I could not identify corresponding messages in the logs.
> Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1292) remove dependency-graph in favour of the maven-dependency-tree library

2009-12-01T16:04:55Z


    [ http://jira.codehaus.org/browse/MRM-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200158#action_200158
] 

Brett Porter commented on MRM-1292:
-----------------------------------

done on the MRM-1025 branch

> remove dependency-graph in favour of the maven-dependency-tree library
> ----------------------------------------------------------------------
>
>                 Key: MRM-1292
>                 URL: http://jira.codehaus.org/browse/MRM-1292
>             Project: Archiva
>          Issue Type: Improvement
>          Components: browser
>    Affects Versions: 1.2.2
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> the dependency graph module is only used to render the dependency tree on the artifact
information pages. It currently reproduces a lot of Maven functionality, and is heavily tied
to the archiva-repository-layer and archiva-model.
> We should instead use the standard Maven library for handling Maven dependency trees.
If we later encounter different types of trees, we can provide alternative implementations.
It's unlikely something as generic is needed (though the code is still there to be revisited
in SVN if the case arises)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1292) remove dependency-graph in favour of the maven-dependency-tree library

2009-12-01T16:00:55Z


     [ http://jira.codehaus.org/browse/MRM-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter updated MRM-1292:
------------------------------

    Fix Version/s: 1.3
         Assignee: Brett Porter

> remove dependency-graph in favour of the maven-dependency-tree library
> ----------------------------------------------------------------------
>
>                 Key: MRM-1292
>                 URL: http://jira.codehaus.org/browse/MRM-1292
>             Project: Archiva
>          Issue Type: Improvement
>          Components: browser
>    Affects Versions: 1.2.2
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> the dependency graph module is only used to render the dependency tree on the artifact
information pages. It currently reproduces a lot of Maven functionality, and is heavily tied
to the archiva-repository-layer and archiva-model.
> We should instead use the standard Maven library for handling Maven dependency trees.
If we later encounter different types of trees, we can provide alternative implementations.
It's unlikely something as generic is needed (though the code is still there to be revisited
in SVN if the case arises)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1292) remove dependency-graph in favour of the maven-dependency-tree library

2009-12-01T16:00:55Z

remove dependency-graph in favour of the maven-dependency-tree library
----------------------------------------------------------------------

                 Key: MRM-1292
                 URL: http://jira.codehaus.org/browse/MRM-1292
             Project: Archiva
          Issue Type: Improvement
          Components: browser
    Affects Versions: 1.2.2
            Reporter: Brett Porter


the dependency graph module is only used to render the dependency tree on the artifact information
pages. It currently reproduces a lot of Maven functionality, and is heavily tied to the archiva-repository-layer
and archiva-model.

We should instead use the standard Maven library for handling Maven dependency trees. If we
later encounter different types of trees, we can provide alternative implementations. It's
unlikely something as generic is needed (though the code is still there to be revisited in
SVN if the case arises)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1291) Archiva has periodic load-peaks

2009-12-01T15:45:55Z


     [ http://jira.codehaus.org/browse/MRM-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Marc Lustig updated MRM-1291:
-----------------------------

    Attachment: screenshot-1.jpg

Please have a look at the second stat-chart by Munin.
Unfortunately we miss the data between week 46 and 48.

But when you look at the filled area in week 45, you can see very the apparent load-difference
between normal scanning peaks and "overblown" scanning-peaks.

By the way, we do not have any other software running on that server.

> Archiva has periodic load-peaks 
> --------------------------------
>
>                 Key: MRM-1291
>                 URL: http://jira.codehaus.org/browse/MRM-1291
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.2.2
>         Environment: RHEL4, Oracle RDBMS
>            Reporter: Marc Lustig
>         Attachments: cpu-day.png, screenshot-1.jpg
>
>
> Archiva causes periodically an increased system-load. (see Munin-stats attached)
> During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.
> I could not identify corresponding messages in the logs.
> Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1291) Archiva has periodic load-peaks

2009-12-01T15:43:55Z


    [ http://jira.codehaus.org/browse/MRM-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200153#action_200153
] 

Marc Lustig commented on MRM-1291:
----------------------------------

This pretty much sounds like a reasonable explanation - unfortunately it may not be the (only)
reason.

I forgot to mention that this "periodic peaks" load-pattern occurs only from time to time.
I. e. when the pattern happens, the peaks occur periodically. But after restarting Archiva,
the pattern does not occur anymore for a couple of days or weeks.

I can be sure about this because we have notifiers installed that warn when a certain HTTP-request
on Archiva exceeds a certain threshold value.
We have not seen alarms between 3rd of november and 30th of november.
On the 30th out of a sudden the periodic load raised tremendously.

I doubt the RDBMS being slower could have an impact on the load.



> Archiva has periodic load-peaks 
> --------------------------------
>
>                 Key: MRM-1291
>                 URL: http://jira.codehaus.org/browse/MRM-1291
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.2.2
>         Environment: RHEL4, Oracle RDBMS
>            Reporter: Marc Lustig
>         Attachments: cpu-day.png
>
>
> Archiva causes periodically an increased system-load. (see Munin-stats attached)
> During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.
> I could not identify corresponding messages in the logs.
> Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1291) Archiva has periodic load-peaks

2009-12-01T09:48:55Z

Archiva has periodic load-peaks 
--------------------------------

                 Key: MRM-1291
                 URL: http://jira.codehaus.org/browse/MRM-1291
             Project: Archiva
          Issue Type: Bug
          Components: system
    Affects Versions: 1.2.2
         Environment: RHEL4, Oracle RDBMS
            Reporter: Marc Lustig
         Attachments: cpu-day.png

Archiva causes periodically an increased system-load. (see Munin-stats attached)

During these peaks calling the homepage takes around 6 secs, whereas normally it is around
1 sec.

I could not identify corresponding messages in the logs.

Could somebody else observe this?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1288) migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API

2009-11-30T16:11:55Z


    [ http://jira.codehaus.org/browse/MRM-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200027#action_200027
] 

Brett Porter commented on MRM-1288:
-----------------------------------

this is now done on the MRM-1025 branch

> migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API
> ------------------------------------------------------------------------------------
>
>                 Key: MRM-1288
>                 URL: http://jira.codehaus.org/browse/MRM-1288
>             Project: Archiva
>          Issue Type: Improvement
>          Components: xmlrpc
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> see MRM-1025 for more information

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Archiva Connection Refused Error

2009-11-30T12:34:16Z

Hi all,
I am using Archiva 2.2.1
Apache Maven 2.2.1 (r801777; 2009-08-06 20:16:01+0100)
Java version: 1.5.0_06
Java home: /usr/java/jdk1.5.0_06/jre
OS name: "linux" version: "2.6.18-92.el5xen" arch: "i386" Family: "unix"

*Problem 1:*
I have recently moved my standalone Archiva Instance into a new server with
improved speed and capacity, and have observed number of "Connection
refused" problems in my Continuous Integration instances due to Archiva
dropping the connection. Here is the log which I am getting:

[INFO]
------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error retrieving previous build number for artifact
'com.specsavers.ott:hub-data-repository-service-unit:jbi-service-unit':
repository metadata for: 'snapshot
com.specsavers.ott:hub-data-repository-service-unit:1.4.3-SNAPSHOT' could
not be retrieved from repository: srs-snapshot due to an error: Error
transferring file: Connection refused
[INFO]
------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 25 minutes 50 seconds
[INFO] Finished at: Mon Nov 30 10:01:41 GMT 2009
[INFO] Final Memory: 77M/373M
[INFO]
------------------------------------------------------------------------

My old archiva instance was running on a similar server and in the same
network.


Can anyone please comment about this behavior and provide me any kind of
pointers to get this resolved.

I am also working with my network team to see if there are any problems due
to network, (haven't noticed anything yet since 2 weeks, network looks to be
normal and working fine)


Problem 2:
When build projects, Archiva is doing a lookup in INTERNET for project
generated Artifacts FROM Remote repository defined. I think there is
something wrong with the archiva configuration. Also we are using "master"
as mirror of all repositories. Could that be a problem?


These problems are of critical importance to our projects and it would be
really helpful if you could please provide me with your
inputs/pointers/comments/resolution upon the same.

Thanks in advance!!

-- 
Thanks & Regards,
Soumen Trivedi
+44 (0) 751 544 6779
Email: Soumen.Trivedi@gmail.com

[jira] Closed: (MRM-1290) getDependees always returns results for archiva-test in xmlrpc

2009-11-30T02:41:55Z


     [ http://jira.codehaus.org/browse/MRM-1290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter closed MRM-1290.
-----------------------------

       Resolution: Fixed
    Fix Version/s: 1.2.3
         Assignee: Brett Porter

> getDependees always returns results for archiva-test in xmlrpc
> --------------------------------------------------------------
>
>                 Key: MRM-1290
>                 URL: http://jira.codehaus.org/browse/MRM-1290
>             Project: Archiva
>          Issue Type: Bug
>          Components: xmlrpc
>    Affects Versions: 1.2.2
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.2.3
>
>
> incorrect hardcoding

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1290) getDependees always returns results for archiva-test in xmlrpc

2009-11-30T02:37:55Z

getDependees always returns results for archiva-test in xmlrpc
--------------------------------------------------------------

                 Key: MRM-1290
                 URL: http://jira.codehaus.org/browse/MRM-1290
             Project: Archiva
          Issue Type: Bug
          Components: xmlrpc
    Affects Versions: 1.2.2
            Reporter: Brett Porter


incorrect hardcoding

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1289) need to document changes to wrapper.conf on upgrade

2009-11-30T00:47:55Z


     [ http://jira.codehaus.org/browse/MRM-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter updated MRM-1289:
------------------------------

    Fix Version/s: 1.2.3

> need to document changes to wrapper.conf on upgrade
> ---------------------------------------------------
>
>                 Key: MRM-1289
>                 URL: http://jira.codehaus.org/browse/MRM-1289
>             Project: Archiva
>          Issue Type: Task
>          Components: documentation
>    Affects Versions: 1.2.3
>            Reporter: Brett Porter
>             Fix For: 1.2.3
>
>
> the new release moves to a new version of Jetty and changes the library contents listed
in wrapper.conf. Anyone that has a copy of it in their $ARCHIVA_BASE directory (if separate
from the installation) will need to update it with the one from the new distribution

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1289) need to document changes to wrapper.conf on upgrade

2009-11-30T00:45:55Z

need to document changes to wrapper.conf on upgrade
---------------------------------------------------

                 Key: MRM-1289
                 URL: http://jira.codehaus.org/browse/MRM-1289
             Project: Archiva
          Issue Type: Task
          Components: documentation
    Affects Versions: 1.2.3
            Reporter: Brett Porter


the new release moves to a new version of Jetty and changes the library contents listed in
wrapper.conf. Anyone that has a copy of it in their $ARCHIVA_BASE directory (if separate from
the installation) will need to update it with the one from the new distribution

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1097) Error 500 "too many open files"

2009-11-29T11:14:55Z


    [ http://jira.codehaus.org/browse/MRM-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199912#action_199912
] 

Marc Lustig commented on MRM-1097:
----------------------------------

Hi Brent, we did not use LDAP authentication.

> Error 500 "too many open files"
> -------------------------------
>
>                 Key: MRM-1097
>                 URL: http://jira.codehaus.org/browse/MRM-1097
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.1.3
>         Environment: Linux RedHat, Tomcat 6 + Native Connector
>            Reporter: Marc Lustig
>             Fix For: 1.3
>
>
> In our start-script we have configured "ulimit -n 10000"
> But still, occassionally we get http error 500 "java.io.FileNotFoundException ... (Too
many open files)" on a Maven-artifact-request.
> I suppose the files are not properly closed after they are delivered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1097) Error 500 "too many open files"

2009-11-28T23:10:55Z


    [ http://jira.codehaus.org/browse/MRM-1097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199883#action_199883
] 

Brent N Atkinson commented on MRM-1097:
---------------------------------------

Marc, are you using LDAP authentication/authorization when you experience this? I just patched
my Archiva servers because they would halt when downloading a large number of artifacts. It
turned out to be caused by LDAP connection leaks. I have fixed the leaks and can now download
hundreds/thousands of artifacts without hitting the file descriptor limit. If you think you
might be experiencing this, check out http://jira.codehaus.org/browse/REDBACK-185. I'll be
submitting a patch soon.

> Error 500 "too many open files"
> -------------------------------
>
>                 Key: MRM-1097
>                 URL: http://jira.codehaus.org/browse/MRM-1097
>             Project: Archiva
>          Issue Type: Bug
>          Components: system
>    Affects Versions: 1.1.3
>         Environment: Linux RedHat, Tomcat 6 + Native Connector
>            Reporter: Marc Lustig
>             Fix For: 1.3
>
>
> In our start-script we have configured "ulimit -n 10000"
> But still, occassionally we get http error 500 "java.io.FileNotFoundException ... (Too
many open files)" on a Maven-artifact-request.
> I suppose the files are not properly closed after they are delivered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1283) migrate Archiva's "browse" functionality to use the metadata content repository API

2009-11-28T11:50:55Z


    [ http://jira.codehaus.org/browse/MRM-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199851#action_199851
] 

Brett Porter commented on MRM-1283:
-----------------------------------

enhanced to import any missing information from the backing storage repository on-demand

> migrate Archiva's "browse" functionality to use the metadata content repository API
> -----------------------------------------------------------------------------------
>
>                 Key: MRM-1283
>                 URL: http://jira.codehaus.org/browse/MRM-1283
>             Project: Archiva
>          Issue Type: Improvement
>          Components: browser, web application
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> the first steps to removing direct interaction with the database - see MRM-1025 for more
information.
> A test of the API's implementation will be that we can utilise it directly from the webapp
action classes without introducing additional business logic, and such that we can comfortably
use it in the same way from the XMLRPC module. However, we also do not want presentation-related
logic (or at least the organisation of the information on screen) in the repository implementation.
If that is needed, a simpler replacement abstraction for RepositoryBrowsing may be appropriate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MRM-1288) migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API

2009-11-28T00:29:55Z

migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API
------------------------------------------------------------------------------------

                 Key: MRM-1288
                 URL: http://jira.codehaus.org/browse/MRM-1288
             Project: Archiva
          Issue Type: Improvement
          Components: xmlrpc
            Reporter: Brett Porter


see MRM-1025 for more information

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Assigned: (MRM-1288) migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API

2009-11-28T00:29:55Z


     [ http://jira.codehaus.org/browse/MRM-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter reassigned MRM-1288:
---------------------------------

    Assignee: Brett Porter

> migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API
> ------------------------------------------------------------------------------------
>
>                 Key: MRM-1288
>                 URL: http://jira.codehaus.org/browse/MRM-1288
>             Project: Archiva
>          Issue Type: Improvement
>          Components: xmlrpc
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> see MRM-1025 for more information

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MRM-1288) migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API

2009-11-28T00:29:55Z


     [ http://jira.codehaus.org/browse/MRM-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Brett Porter updated MRM-1288:
------------------------------

    Fix Version/s: 1.3

> migrate XMLRPC from DefaultRepositoryBrowsing to the metadata content repository API
> ------------------------------------------------------------------------------------
>
>                 Key: MRM-1288
>                 URL: http://jira.codehaus.org/browse/MRM-1288
>             Project: Archiva
>          Issue Type: Improvement
>          Components: xmlrpc
>            Reporter: Brett Porter
>             Fix For: 1.3
>
>
> see MRM-1025 for more information

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MRM-1282) introduce a metadata content repository API

2009-11-28T00:23:55Z


    [ http://jira.codehaus.org/browse/MRM-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199818#action_199818
] 

Brett Porter commented on MRM-1282:
-----------------------------------

this is now in place on the branch

> introduce a metadata content repository API
> -------------------------------------------
>
>                 Key: MRM-1282
>                 URL: http://jira.codehaus.org/browse/MRM-1282
>             Project: Archiva
>          Issue Type: Improvement
>            Reporter: Brett Porter
>            Assignee: Brett Porter
>             Fix For: 1.3
>
>
> see MRM-1025 for justification

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira