Ok, I see what you mean now. We're getting a recurring theme on this. We're seeing poor performance from the indexer library (which we're looking into upgrading).
This results in two states: - very long indexing queues, causing hangs & restarts (MRM-1420) - file handle exhaustion, causing restarts (MRM-1419) The only workaround is to minimize the indexing work your repository has to do. Typically it's a good idea to reduce the scanning interval to an off-peak period only (if you're deploying by HTTP, there'll be no functional difference). You can further tune the scanning settings by repository and artifact type from the administration pages as well. Hopefully we'll have a resolution on dev@ to this shortly. - Brett On 05/10/2010, at 8:24 AM, Michael Delaney wrote: > > No, by the time I get around to it there isn't an error. I normally find the > error in my Hudson builds. > > We just had nine builds fail, all at the same time, all getting an error code > 500. When I look in the logs, I see that for some reason Archiva had > restarted for some reason. That seems odd to me. We haven't changed JDK's > (1.5.0_24). > > INFO | jvm 1 | 2010/10/01 12:36:49 | 896 [WrapperSimpleAppMain] WARN > org.mortbay.log - Deprecated configuration used for ./apps > INFO | jvm 1 | 2010/10/01 12:36:49 | 1443 [WrapperSimpleAppMain] INFO > org.mortbay.log - Redirecting stderr/stdout to > /srv/archiva/logs/2010_10_01.stderrout.log > ERROR | wrapper | 2010/10/04 17:02:07 | JVM appears hung: Timed out waiting > for signal from JVM. > ERROR | wrapper | 2010/10/04 17:02:08 | JVM did not exit on request, > terminated > INFO | wrapper | 2010/10/04 17:02:08 | JVM exited on its own while waiting > to kill the application. > STATUS | wrapper | 2010/10/04 17:02:08 | JVM exited in response to signal > SIGKILL (9). > STATUS | wrapper | 2010/10/04 17:02:37 | Launching a JVM... > INFO | jvm 2 | 2010/10/04 17:02:38 | Wrapper (Version 3.2.3) > http://wrapper.tanukisoftware.org > INFO | jvm 2 | 2010/10/04 17:02:38 | Copyright 1999-2006 Tanuki > Software, Inc. All Rights Reserved. > INFO | jvm 2 | 2010/10/04 17:02:38 | > INFO | jvm 2 | 2010/10/04 17:02:39 | 1 [WrapperSimpleAppMain] INFO > org.mortbay.log - Logging to org.slf4j.impl.SimpleLogger(org.mortbay.log) via > org.mortbay.log.Slf4jLog > INFO | jvm 2 | 2010/10/04 17:02:39 | 477 [WrapperSimpleAppMain] WARN > org.mortbay.log - Deprecated configuration used for ./apps > INFO | jvm 2 | 2010/10/04 17:02:40 | 1228 [WrapperSimpleAppMain] INFO > org.mortbay.log - Redirecting stderr/stdout to > /srv/archiva/logs/2010_10_04.stderrout.log > > > > > On 10/3/2010 7:06 PM, Brett Porter wrote: >> When you hit the URL in a browser, does the page give you any more details >> about the 500 error? >> >> It's unusual for it not to show up in the server logs. >> >> On 03/10/2010, at 3:01 AM, Delaney, Michael wrote: >> >>> Yes, over 40Gb free on the server. >>> ________________________________________ >>> From: [email protected] [[email protected]] On Behalf Of Deng Ching >>> [[email protected]] >>> Sent: Saturday, October 02, 2010 12:06 AM >>> To: [email protected] >>> Subject: Re: HTTP code 500 when trying to access a artifact. >>> >>> Hi, >>> >>> Did you check if there is enough disk space in your server? >>> >>> Thanks, >>> Deng >>> >>> On Sat, Oct 2, 2010 at 1:13 AM, Michael Delaney<[email protected]> >>> wrote: >>>> I'm not seeing any exceptions but I am seeing the entries in request log >>>> that contain the 500 error codes. >>>> >>>> On 9/30/2010 7:19 PM, Brett Porter wrote: >>>>> Do you see anything in the archiva server log that would correspond to the >>>>> return of the 500 code? >>>>> >>>>> - Brett >>>>> >>>>> On 01/10/2010, at 1:13 AM, Michael Delaney wrote: >>>>> >>>>>> All, >>>>>> >>>>>> Our Archiva 1.1.2 server has started to act up a lot as of late. We're >>>>>> seeing some 500 error codes when trying to deply our artifacts. We're >>>>>> also >>>>>> seeing some behavior where an artifact is uploaded to Archiva (any type: >>>>>> pom, zip, jar, war; of varying size) but build freezes during the >>>>>> "upload" >>>>>> process. The newly updated file is accessible via WGET/HTTP calls but the >>>>>> build doesn't progress. >>>>>> >>>>>> I assume this requires me to bump a logging value in log4j but I'm not >>>>>> sure which ones I should bump; or just brute force it and bump all of >>>>>> them. >>>>>> >>>>>> [ Error Snippet ] >>>>>> [INFO] Error deploying artifact: Failed to transfer file: >>>>>> http://archiva:8080/archiva/repository/snapshot/groupId/myProject/1.0.0-SNAPSHOT/myProject-1.0.0-20100930.010002-48-config.jar. >>>>>> Return code is: 500 >>>>>> >>>>>> >>>>> -- >>>>> Brett Porter >>>>> [email protected] >>>>> http://brettporter.wordpress.com/ >>>>> >>>>> >>>>> >>>>> >>>>> >> -- >> Brett Porter >> [email protected] >> http://brettporter.wordpress.com/ >> >> >> >> >> -- Brett Porter [email protected] http://brettporter.wordpress.com/
