[
http://jira.codehaus.org/browse/MRM-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-465:
-------------------------------
Description:
When having a process/tool (such as siege) hit the artifact browsing pages on
archiva in rapid succession, the archiva application becomes unresponsive.
Possible reason: when the first request hits to get the effective pom, the
build of that effective pom starts, but before it has a chance to finish,
another request arrives to do the same thing, and the process starts again,
resources and such get eaten up fast in that scenario.
Possible solution:
HTML2TextReader.listItemPrefixLock the effective pom resolution on a per
groupId:artifactId:version level.
HTML2TextReader.listItemPrefixCache the effective pom on disk.
HTML2TextReader.listItemPrefix(option 1) save the effective pom to disk in the
groupId:artifactId:version location using the extension ".effective.pom"
HTML2TextReader.listItemPrefix(option 2) save the effective pom to a long lived
e
was:
When having a process/tool (such as siege) hit the artifact browsing pages on
archiva in rapid succession, the archiva application becomes unresponsive.
Possible reason: when the first request hits to get the effective pom, the
build of that effective pom starts, but before it has a chance to finish,
another request arrives to do the same thing, and the process starts again,
resources and such get eaten up fast in that scenario.
Possible solution:
* Lock the effective pom resolution on a per groupId:artifactId:version level.
* Cache the effective pom on disk.
** (option 1) save the effective pom to disk in the groupId:artifactId:version
location using the extension ".effective.pom"
** (option 2) save the effective pom to a long lived ehcache (backed on disk,
in ehcache format)
Added to the cache the merged parent pom's seems to have done the trick.
Tests no longer hang the server.
Will require more tests from other devs.
> [Load Testing] When asking for pages that require the effective-pom in high
> load, app becomes unresponsive.
> -----------------------------------------------------------------------------------------------------------
>
> Key: MRM-465
> URL: http://jira.codehaus.org/browse/MRM-465
> Project: Archiva
> Issue Type: Bug
> Components: browser
> Affects Versions: 1.0-beta-2
> Reporter: Joakim Erdfelt
> Assignee: Joakim Erdfelt
> Priority: Critical
> Attachments: archiva-OutOfMemoryError_during_jpox.log
>
>
> When having a process/tool (such as siege) hit the artifact browsing pages on
> archiva in rapid succession, the archiva application becomes unresponsive.
> Possible reason: when the first request hits to get the effective pom, the
> build of that effective pom starts, but before it has a chance to finish,
> another request arrives to do the same thing, and the process starts again,
> resources and such get eaten up fast in that scenario.
> Possible solution:
> HTML2TextReader.listItemPrefixLock the effective pom resolution on a per
> groupId:artifactId:version level.
> HTML2TextReader.listItemPrefixCache the effective pom on disk.
>
> HTML2TextReader.listItemPrefix(option 1) save the effective pom to disk in
> the groupId:artifactId:version location using the extension ".effective.pom"
>
> HTML2TextReader.listItemPrefix(option 2) save the effective pom to a long
> lived e
--
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
