Mailing-List: contact users-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@archiva.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <518FC8A3.3050206@free.fr>
Date: Sun, 12 May 2013 18:51:47 +0200
From: Patrice Ringot <okulea@free.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: users@archiva.apache.org
Subject: Re: Archiva 1.4 M3/M4 on Raspberry PI
References: <518EC894.7090406@free.fr>
 <CAPoyBqTwij8tph06Bpjrtf+-WW_KkTGCh_2F4DAWXpQ_qe+ONg@mail.gmail.com>
 <518F907E.2060605@free.fr>
 <CAPoyBqT-K=ODx0y_ZUSj0HW-o4+8QYbSqoCx3n-Uw8CaSjJT-A@mail.gmail.com>
In-Reply-To: 
 <CAPoyBqT-K=ODx0y_ZUSj0HW-o4+8QYbSqoCx3n-Uw8CaSjJT-A@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020301050107030106080704"

--------------020301050107030106080704
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

That's it !

Even the Raspberry is happy ... (including 1.4.M4 startup time which is 
now comparable with what I obtained with the 1.4M3 version). Back in the 
game !

The property to set was :

-DAsyncLoggerConfig.WaitStrategy=Block

(see http://logging.apache.org/log4j/2.x/manual/async.html)

Please, if you can, leave this choice open to the user, maybe adding the 
following lines in the wrapper.conf files:

wrapper.java.additional.7=-DAsyncLoggerConfig.WaitStrategy=Block
#wrapper.java.additional.7=-DAsyncLoggerConfig.WaitStrategy=Sleep

Thanks for your help !

Patrice

PS: the Raspberry is your friend for performance issues because when it 
is hurt, this is visible (a kind of stress test ...)

Le 12/05/2013 15:03, Olivier Lamy a �crit :
> Thanks for this analysis !
> In last version I moved to use new asyncLogger from log4j2 (see
> http://logging.apache.org/log4j/2.x/manual/async.html) which use
> disruptor library.
> I don't know yet if it's a good idea or not :-) but your value (on a
> "classic" env) doesn't look to be an excessive.
> Can you try the same analysis with the system property
> -DAsyncLogger.WaitStrategy=Block ? (see the possible values in the
> log4j2 documentation page).
>
>
>
> 2013/5/12 Patrice Ringot <okulea@free.fr>:
>> Hello,
>>
>> Just an update about performance. After more work with the 1.4M4-SNAPSHOT
>> (as of 5/11/2013) on the Raspberry, I noticed using htop that this version
>> consumes more CPU comparing to the 1.4M3 version in the same context (don't
>> be afraid by startup time of M3 on the PI, remember: it is indeed a slow
>> machine ...).
>>
>>     1) initial startup time (fresh install, time to go to the alpacas
>> banner):
>>
>>          - 5mn 47s with 1.4M3
>>          - 14mn 23s with 1.4M4-SNAPSHOT
>>
>>     2) when Archiva is not used, htop shows that :
>>
>>          - the 1.4M3 version consumes no CPU
>>          - the 1.4M4 snapshot version has a thread consuming roughly 88% of
>> the ARM V6 CPU
>>
>> So I made the same test on a OpenSuse 12.2 vmware-ized on a i7 + SSD (using
>> OpenJDK 7 1.7.0_21, 64 bits) and I obtained the following results:
>>
>>     1) initial startup time (fresh install, time to go to the alpacas
>> banner):
>>
>>          - 20s with 1.4M3,
>>          - 20s with 1.4M4-SNAPSHOT
>>
>>     2) when Archiva is not used, htop shows that :
>>
>>          - the 1.4M3 version consumes no CPU (just like the 1.3.6 version)
>>          - the 1.4M4 snapshot version has a thread consuming roughly 10% of
>> the i7 CPU
>>
>> Archiva on the Raspberry and its preview JDK8 is definitely not a common use
>> case for Archiva (maybe it will be in one or two years with 2x or 4x more
>> powerful boards ?).
>>
>> But still, the difference exists between the M3 and M4 version on a more
>> conventional Archiva target.
>>
>> Is it something new or did I do something wrong ?
>>
>> Regards
>>
>> Patrice
>>
>> PS: using jstack and the thread pid(dec)/nid(hex) identifier, it seems that
>> the thread involved is the same in both cases:
>>
>> Raspbian/Oracle JDK8:
>> "pool-2-thread-1" #28 prio=5 os_prio=0 tid=0x00ec62c0 nid=0x1434 runnable
>> [0x9e644000]
>>     java.lang.Thread.State: TIMED_WAITING (parking)
>>          at sun.misc.Unsafe.park(Native Method)
>>          at
>> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:349)
>>          at
>> com.lmax.disruptor.SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66)
>>          at
>> com.lmax.disruptor.SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39)
>>          at
>> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55)
>>          at
>> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:115)
>>          at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
>>          at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
>>          at java.lang.Thread.run(Thread.java:722)
>>
>> OpenSuse/OpenJDK7:
>> "pool-2-thread-1" prio=10 tid=0x00007faa28c6c000 nid=0x6082 runnable
>> [0x00007faa76bcb000]
>>     java.lang.Thread.State: TIMED_WAITING (parking)
>>          at sun.misc.Unsafe.park(Native Method)
>>          at
>> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:349)
>>          at
>> com.lmax.disruptor.SleepingWaitStrategy.applyWaitMethod(SleepingWaitStrategy.java:66)
>>          at
>> com.lmax.disruptor.SleepingWaitStrategy.waitFor(SleepingWaitStrategy.java:39)
>>          at
>> com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:55)
>>          at
>> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:115)
>>          at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>          at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>          at java.lang.Thread.run(Thread.java:722)
>>
>>
>> Le 12/05/2013 09:21, Olivier Lamy a �crit :
>>
>>> 2013/5/12 Patrice Ringot <okulea@free.fr>:
>>>> Hello
>>>>
>>>> Just for information: the latest snapshot of 1.4-M4 I have downloaded
>>>> today
>>>> is able to run decently on a Raspberry PI model B (512MB) under Raspbian
>>>> Wheezy and
>>>> the Nov 12 preview of the Oracle JDK 8 for ARM processors. The UI is
>>>> responsive, and the utilization of Maven is very acceptable for a home
>>>> network (I have just modified the
>>>> -Xmx parameter to 256M instead of the 512MB default).
>>>>
>>> Good to know thanks for sharing !
>>>
>>>> The only thing that do not work out of the box is the Tanuki wrapper as
>>>> it
>>>> is packaged in the current distribution; it is too old to contain the
>>>> required ARM files
>>>> (the latest one from SourceForge is OK).
>>> Due to license reasons we cannot upgrade.
>>> License has changed to GPL see
>>> http://wrapper.tanukisoftware.com/doc/english/licenseOverview.html
>>>
>>>> Another thing I have  noted (unrelated to the Raspberry or this
>>>> particular
>>>> version of Archiva) concerns the content of the wrapper.conf file: it
>>>> contains the version of each jar in the classpath. As I initially used it
>>>> as
>>>> a template in my Archiva puppet module, I had a problem when I made the
>>>> 1.4-M3 -> 1.4-M4 update "in place" (class not found since the jars
>>>> filenames
>>>> have naturally changed between these two versions).
>>>>
>>>> Extract from wrapper.conf:
>>>>
>>>> # Java Classpath (include wrapper.jar)  Add class path elements as
>>>> #  needed starting from 1
>>>> wrapper.java.classpath.1=lib/wrapper.jar
>>>> wrapper.java.classpath.2=%REPO_DIR%/archiva-jetty-1.4-M4-SNAPSHOT.pom
>>>> wrapper.java.classpath.3=%REPO_DIR%/jetty-server-8.1.9.v20130131.jar
>>>> wrapper.java.classpath.4=%REPO_DIR%/javax.servlet-3.0.0.v201112011016.jar
>>>>
>>>> wrapper.java.classpath.5=%REPO_DIR%/jetty-continuation-8.1.9.v20130131.jar
>>>> ...
>>>>
>>>> So I have changed my way of dealing with this file, but I remembered that
>>>> I
>>>> did not encountered this problem with the
>>>> ElasticSearch service wrapper; actually they manage the classpath
>>>> differently:
>>>>
>>>> # Java Classpath (include wrapper.jar)  Add class path elements as
>>>> #  needed starting from 1
>>>> wrapper.java.classpath.1=%ES_HOME%/bin/service/lib/wrapper.jar
>>>> wrapper.java.classpath.2=%ES_HOME%/lib/elasticsearch*.jar
>>>> wrapper.java.classpath.3=%ES_HOME%/lib/*.jar
>>>> wrapper.java.classpath.4=%ES_HOME%/lib/sigar/*.jar
>>>>
>>>> Using the * wildcard makes  wrapper.conf and Archiva versions much more
>>>> independant of each other.
>>> Good idea that's something to test.
>>> Maybe only one line with
>>> wrapper.java.classpath.2=%REPO_DIR%/*.jar
>>> Any time to propose a patch ?
>>>
>>>> Regards
>>>>
>>>> Patrice
>>>>
>>>> PS: I have also tested artifacts deletion in the snapshot repository and
>>>> it
>>>> was OK for me. This is very convenient.
>>>>
>>>>
>>>
>>> --
>>> Olivier Lamy
>>> Ecetera: http://ecetera.com.au
>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>
>>>
>
>


--------------020301050107030106080704--