You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@archiva.apache.org by Patrice Ringot <ok...@free.fr> on 2013/05/12 00:39:16 UTC
Archiva 1.4 M3/M4 on Raspberry PI
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).
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).
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.
Regards
Patrice
PS: I have also tested artifacts deletion in the snapshot repository and
it was OK for me. This is very convenient.
Re: Archiva 1.4 M3/M4 on Raspberry PI
Posted by Olivier Lamy <ol...@apache.org>.
2013/5/13 Patrice Ringot <ok...@free.fr>:
> 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
Sounds good, I will try to change that except if you beat me sending a patch :-)
>
> 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 ...)
LOL :-)
>
> 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 <ok...@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 <ok...@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
>>>>
>>>>
>>
>>
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva 1.4 M3/M4 on Raspberry PI
Posted by Patrice Ringot <ok...@free.fr>.
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 <ok...@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 <ok...@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
>>>
>>>
>
>
Re: Archiva 1.4 M3/M4 on Raspberry PI
Posted by Olivier Lamy <ol...@apache.org>.
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 <ok...@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 <ok...@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
>>
>>
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: Archiva 1.4 M3/M4 on Raspberry PI
Posted by Patrice Ringot <ok...@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 <ok...@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
>
>
Re: Archiva 1.4 M3/M4 on Raspberry PI
Posted by Olivier Lamy <ol...@apache.org>.
2013/5/12 Patrice Ringot <ok...@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