RE: Redback core issue with jdk 1.7 as prerequisite

2014-04-14 Thread Eric Barboni
1.6 fallback is enough for me (for now)
But If it's time to move to new tech or framework, I'm seriously out of
knowledge (or rationale) on where to go.

-Message d'origine-
De : Brett Porter [mailto:br...@porterclan.net] De la part de Brett Porter
Envoyé : vendredi 11 avril 2014 03:02
À : dev@archiva.apache.org
Objet : Re: Redback core issue with jdk 1.7 as prerequisite


On 11 Apr 2014, at 10:03 am, Olivier Lamy  wrote:

> Hi,
> So we use a pretty old jpox stack which do bytecode enhancement with bcel.
> This generate bad bytecode when compiling with 1.7 (if compiler target 
> 1.7)
> 
> Solutions I have in mind:
> * stay as today not having 1.7 as prerequisite for redback core 
> (that's what I just did) (compiler target/source 1.6)

Seems the best immediate solution.

> * moving to a new technology (openjpa?)
> 
> Regarding the last option, does it mean reusing same database model or 
> using a new one but with  a data migration tooling?
> 
> Thoughts?

If you're going to do that amount of work, I think it's worth seriously
considering if another framework (Shiro, Spring Security) might better fit
the needs, and either replace Redback or reduce it down to things on top of
that. But I'm not volunteering :)

- Brett




Re: 100% CPU on Debian

2014-04-14 Thread Olivier Lamy
yup make sense to change default value
http://jira.codehaus.org/browse/MRM-1829

Olivier

On 13 April 2014 19:19, Chris Graham  wrote:
> Hi All.
>
> Given my experiences with the excessive CPU :) The Log4j2 guys are/have
> considering the change of the default from Sleep (?) to Block.
>
> From what I understand of my case, they were trying to sleep for 1ns. Intel
> rounds up to the nearest mSec. AIX doesn't. It will sleep for 1ns...
>
> So they are considering the change to Block. I'm not sure if they've done
> it yet (or will).
>
> -Chris
>
>
>
> On Sat, Apr 12, 2014 at 8:36 PM, Brett Porter  wrote:
>
>> Given the number of reports, should we change the default? What is the
>> advantage of the current default?
>>
>> It sounds like this is related to the number of cores available, can we
>> select the best default option based on
>> http://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html#availableProcessors()?
>>
>> - Brett
>>
>> On 12 Apr 2014, at 10:43 am, Olivier Lamy  wrote:
>>
>> > maybe log4j2 async with disruptor.
>> > See
>> http://archiva.apache.org/docs/2.0.2-SNAPSHOT/adminguide/logging.html
>> >
>> >
>> > On 12 April 2014 00:43,   wrote:
>> >> Hi,
>> >>
>> >>
>> >>
>> >> I'm attempting to use Archiva on a debian virtualbox and Archiva
>> consumes
>> >> all the CPU.
>> >>
>> >>
>> >>
>> >> I've tested it with several JVM but the problem remain. I've check the
>> linux
>> >> user has access to repository and index folder and I also tries to
>> diagnose
>> >> using jvisualvm but that impossible to see cpu per threads.
>> >>
>> >>
>> >>
>> >> The same 2.0.1 version runs fine on windows 7.
>> >>
>> >>
>> >>
>> >> Log files says that but I don't know if it's the problem:
>> >>
>> >> java.lang.RuntimeException: Unable to update a stale item: item.save()
>> >>
>> >>at
>> >>
>> org.apache.archiva.metadata.repository.jcr.JcrMetadataRepository.save(JcrMet
>> >> adataRepository.java:1238) ~[metadata-store-jcr-2.0.1.jar:?]
>> >>
>> >>at
>> >>
>> org.apache.archiva.metadata.repository.RepositorySession.save(RepositorySess
>> >> ion.java:69) ~[metadata-repository-api-2.0.1.jar:2.0.1]
>> >>
>> >>at
>> >>
>> org.apache.archiva.consumers.metadata.ArchivaMetadataCreationConsumer.proces
>> >> sFile(ArchivaMetadataCreationConsumer.java:204)
>> >> ~[archiva-metadata-consumer-2.0.1.jar:?]
>> >>
>> >>at
>> >>
>> org.apache.archiva.consumers.metadata.ArchivaMetadataCreationConsumer.proces
>> >> sFile(ArchivaMetadataCreationConsumer.java:229)
>> >> ~[archiva-metadata-consumer-2.0.1.jar:?]
>> >>
>> >>at
>> >>
>> org.apache.archiva.repository.scanner.functors.ConsumerProcessFileClosure.ex
>> >> ecute(ConsumerProcessFileClosure.java:60)
>> >> [archiva-repository-scanner-2.0.1.jar:?]
>> >>
>> >>at
>> >>
>> org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:118
>> >> ) [commons-collections-3.2.1.jar:3.2.1]
>> >>
>> >>at
>> >>
>> org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java
>> >> :389) [commons-collections-3.2.1.jar:3.2.1]
>> >>
>> >>at
>> >>
>> org.apache.archiva.repository.scanner.RepositoryScannerInstance.directoryWal
>> >> kStep(RepositoryScannerInstance.java:163)
>> >> [archiva-repository-scanner-2.0.1.jar:?]
>> >>
>> >>at
>> >>
>> org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:174)
>> >> [plexus-utils-3.0.15.jar:?]
>> >>
>> >>at
>> >>
>> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:392)
>> >> [plexus-utils-3.0.15.jar:?]
>> >>
>> >>at
>> >>
>> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:386)
>> >> [plexus-utils-3.0.15.jar:?]
>> >>
>> >>at
>> >>
>> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:386)
>> >> [plexus-utils-3.0.15.jar:?]
>> >>
>> >>at
>> >>
>> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:386)
>> >> [plexus-utils-3.0.15.jar:?]
>> >>
>> >>at
>> >>
>> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:386)
>> >> [plexus-utils-3.0.15.jar:?]
>> >>
>> >>at
>> >> org.codehaus.plexus.util.DirectoryWalker.scan(DirectoryWalker.java:345)
>> >> [plexus-utils-3.0.15.jar:?]
>> >>
>> >>at
>> >>
>> org.apache.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultR
>> >> epositoryScanner.java:133) [archiva-repository-scanner-2.0.1.jar:?]
>> >>
>> >>at
>> >>
>> org.apache.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultR
>> >> epositoryScanner.java:65) [archiva-repository-scanner-2.0.1.jar:?]
>> >>
>> >>at
>> >>
>> org.apache.archiva.rest.services.DefaultRepositoriesService.scanRepositoryDi
>> >> rectoriesNow(DefaultRepositoriesService.java:1090)
>> >> [archiva-rest-services-2.0.1.jar:?]
>> >>
>> >>at sun

Re: Redback core issue with jdk 1.7 as prerequisite

2014-04-14 Thread Olivier Lamy
I believe as we are really Spring based spring-security sounds a good option :-)


On 14 April 2014 19:34, Eric Barboni  wrote:
> 1.6 fallback is enough for me (for now)
> But If it's time to move to new tech or framework, I'm seriously out of
> knowledge (or rationale) on where to go.
>
> -Message d'origine-
> De : Brett Porter [mailto:br...@porterclan.net] De la part de Brett Porter
> Envoyé : vendredi 11 avril 2014 03:02
> À : dev@archiva.apache.org
> Objet : Re: Redback core issue with jdk 1.7 as prerequisite
>
>
> On 11 Apr 2014, at 10:03 am, Olivier Lamy  wrote:
>
>> Hi,
>> So we use a pretty old jpox stack which do bytecode enhancement with bcel.
>> This generate bad bytecode when compiling with 1.7 (if compiler target
>> 1.7)
>>
>> Solutions I have in mind:
>> * stay as today not having 1.7 as prerequisite for redback core
>> (that's what I just did) (compiler target/source 1.6)
>
> Seems the best immediate solution.
>
>> * moving to a new technology (openjpa?)
>>
>> Regarding the last option, does it mean reusing same database model or
>> using a new one but with  a data migration tooling?
>>
>> Thoughts?
>
> If you're going to do that amount of work, I think it's worth seriously
> considering if another framework (Shiro, Spring Security) might better fit
> the needs, and either replace Redback or reduce it down to things on top of
> that. But I'm not volunteering :)
>
> - Brett
>
>



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy