That's pretty much what I thought. Perhaps we can start a discussion at some
point about improving the way that the automated tests are conducted to provide
more "throughput".
As for the second kind of testing, could this be provided without more burden
on the committers if more people/institutions/resources were involved in the
"combinatorial" testing phase? It might even make possible a more
"asynchronous" schedule for conducting that testing. Am I right in thinking
that currently, that testing tends to occur only right before a release?
---
A. Soroka
Online Library Environment
the University of Virginia Library
On Jul 27, 2011, at 10:15 AM, Benjamin Armintor wrote:
> I think the automated tests would need to remain limited to the
> recommended JVM- I wouldn't be able to bear an hour and a half wait
> for the sanity builds. That said, it would be great if we could test
> OpenJDK in the way that we test different RDBMS and OS configurations
> before releases.
>
> On 7/27/11, aj...@virginia.edu <aj...@virginia.edu> wrote:
>> It has to be noted that an additional JVM/JRE could almost double the amount
>> of testing to be done. Fedora testing (as will testify those who are
>> slogging through it for 3.5 even as we speak) is somewhat burdensome.
>>
>> Can Fedora's current testing machinery (including the human resources that
>> power it) support a compounding of load? Or must we be thinking first about
>> that problem before introducing a new platform?
>>
>> ---
>> A. Soroka
>> Online Library Environment
>> the University of Virginia Library
>>
>>
>>
>>
>> On Jul 27, 2011, at 9:02 AM, Edwin Shin wrote:
>>
>>> +1 for openjdk
>>>
>>> On 27 Jul 2011, at 1:37 PM, aj...@virginia.edu wrote:
>>>
>>>> OpenJDK is one with which I've had no problems running Fedora, at least
>>>> on Linux. Some of the others were mixtures of Apache Harmony with other
>>>> VMs. A few of them worked well, others... not so much. {grin} Fedora, in
>>>> fact, became something of an acid test for me looking at alternatives to
>>>> the Oracle product.
>>>>
>>>> OpenJDK, I think, would be far and away the best candidate to add to the
>>>> testing rotation.
>>>>
>>>> ---
>>>> A. Soroka
>>>> Online Library Environment
>>>> the University of Virginia Library
>>>>
>>>>
>>>>
>>>>
>>>> On Jul 25, 2011, at 4:36 PM, Chris Wilper wrote:
>>>>
>>>>> I'm curious -- which other VMs have you used successfully? I've
>>>>> wondered about OpenJDK myself...
>>>>>
>>>>> At any rate,I think it makes sense to at least document the specific
>>>>> settings of the currently-required VM. I'm game for having a list of
>>>>> VMs instead of a single required VM at some point (provided they're
>>>>> Java 6+). But I think if we're going to recommend any other VMs, we
>>>>> really should be testing with them as part of the dev/release cycle.
>>>>>
>>>>> - Chris
>>>>>
>>>>> On Mon, Jul 25, 2011 at 4:01 PM, <aj...@virginia.edu> wrote:
>>>>>> I recognize the requirement, but I happily run Fedora over other
>>>>>> HotSpot-variants in development. My point is only that we would ideally
>>>>>> _not_ require a particular VM, although I also recognize that we
>>>>>> require a certain level of predictability for good support.
>>>>>>
>>>>>> Those options are exactly the ones to which I was referring. They work
>>>>>> perfectly well in our experience, but we have _not_ done real, formal
>>>>>> testing. This might be very worthwhile.
>>>>>>
>>>>>> ---
>>>>>> A. Soroka
>>>>>> Online Library Environment
>>>>>> the University of Virginia Library
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jul 25, 2011, at 3:52 PM, Chris Wilper wrote:
>>>>>>
>>>>>>> Currently we do require the Sun/Oracle version of Java 6, so the
>>>>>>> settings should be consistent across VMs.
>>>>>>>
>>>>>>> Incidently, are you familiar with CMSClassUnloadingEnabled and
>>>>>>> UseConcMarkSweepGC? Apparently both are required to get the Sun/Oracle
>>>>>>> VM to attempt to unload old classes.
>>>>>>>
>>>>>>> But I'm hesitant to recommend much without the actual tuning
>>>>>>> experience.
>>>>>>>
>>>>>>> - Chris
>>>>>>>
>>>>>>> On Mon, Jul 25, 2011 at 11:30 AM, <aj...@virginia.edu> wrote:
>>>>>>>> This is even more relevant for those sites which are running a
>>>>>>>> repository in the same container as other applications (which may be
>>>>>>>> hungry for PermGen themselves).
>>>>>>>>
>>>>>>>> I've never seen the behavior that a repository starts up fine but
>>>>>>>> eventually runs out of PermGen, which suggests against a memory leak,
>>>>>>>> to me. I have many times seen a repository in a container with other
>>>>>>>> apps fail to get up and running very quickly after JVM startup with
>>>>>>>> PermGen problems. My experience has been that Fedora simply had a
>>>>>>>> large appetite for classes and that appetite is fairly constant.
>>>>>>>>
>>>>>>>> We might also consider offering advice (but this would get pretty
>>>>>>>> JVM-specific) about setting class unloading behavior.
>>>>>>>>
>>>>>>>> ---
>>>>>>>> A. Soroka
>>>>>>>> Online Library Environment
>>>>>>>> the University of Virginia Library
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jul 25, 2011, at 8:35 AM, Chris Wilper wrote:
>>>>>>>>
>>>>>>>>> While running ConfigB tests on 3.5-SNAPSHOT with Oracle on Windows 7
>>>>>>>>> x64 last week, the embedded Tomcat gave me the dreaded
>>>>>>>>> "OutOfMemoryError: PermGen Space". Has anyone else seen this yet
>>>>>>>>> when
>>>>>>>>> running 3.5-SNAPSHOT? (particularly on 64-bit Windows or Linux)
>>>>>>>>>
>>>>>>>>> After looking into the problem a bit, I am coming around to the
>>>>>>>>> conclusion that we should be recommending people set a maximum
>>>>>>>>> permgen
>>>>>>>>> size to the VM (e.g. -XX:MaxPermSize=256m).
>>>>>>>>>
>>>>>>>>> Here's what I did after noticing the error:
>>>>>>>>>
>>>>>>>>> 1) Stopped tomcat and added the following line to
>>>>>>>>> %FEDORA_HOME%\tomcat\bin\setclasspath.bat
>>>>>>>>>
>>>>>>>>> set JAVA_OPTS=-Dcom.sun.management.jmxremote.port=8086
>>>>>>>>> -Dcom.sun.management.jmxremote.ssl=false
>>>>>>>>> -Dcom.sun.management.jmxremote.authenticate=false
>>>>>>>>> -XX:MaxPermSize=256m
>>>>>>>>>
>>>>>>>>> 2) Started Tomcat and fired up VisualVM, adding the JMX Connection
>>>>>>>>> to port 8086
>>>>>>>>>
>>>>>>>>> 3) Ran mvn install -Dconfig=B and watched what it said about PermGen
>>>>>>>>> size.
>>>>>>>>>
>>>>>>>>> Here's what I noticed:
>>>>>>>>>
>>>>>>>>> Prior to the tests starting, PermGen was at about 54m with about
>>>>>>>>> 7200
>>>>>>>>> classes loaded.
>>>>>>>>> After the tests ran for a few minutes, PermGen grew and seemed to
>>>>>>>>> level out at about 98m with about 13500 classes loaded.
>>>>>>>>>
>>>>>>>>> It's quite possible we have a classloader leak somewhere. But even
>>>>>>>>> if
>>>>>>>>> we don't, it seems we should be recommending a bigger MaxPermSize
>>>>>>>>> than
>>>>>>>>> the default, 64m.
>>>>>>>>>
>>>>>>>>> - Chris
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Storage Efficiency Calculator
>>>>>>>>> This modeling tool is based on patent-pending intellectual property
>>>>>>>>> that
>>>>>>>>> has been used successfully in hundreds of IBM storage optimization
>>>>>>>>> engage-
>>>>>>>>> ments, worldwide. Store less, Store more with what you own, Move
>>>>>>>>> data to
>>>>>>>>> the right place. Try It Now!
>>>>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>>>>>>>> _______________________________________________
>>>>>>>>> Fedora-commons-developers mailing list
>>>>>>>>> Fedora-commons-developers@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Storage Efficiency Calculator
>>>>>>>> This modeling tool is based on patent-pending intellectual property
>>>>>>>> that
>>>>>>>> has been used successfully in hundreds of IBM storage optimization
>>>>>>>> engage-
>>>>>>>> ments, worldwide. Store less, Store more with what you own, Move
>>>>>>>> data to
>>>>>>>> the right place. Try It Now!
>>>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>>>>>>> _______________________________________________
>>>>>>>> Fedora-commons-developers mailing list
>>>>>>>> Fedora-commons-developers@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Storage Efficiency Calculator
>>>>>>> This modeling tool is based on patent-pending intellectual property
>>>>>>> that
>>>>>>> has been used successfully in hundreds of IBM storage optimization
>>>>>>> engage-
>>>>>>> ments, worldwide. Store less, Store more with what you own, Move data
>>>>>>> to
>>>>>>> the right place. Try It Now!
>>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>>>>>> _______________________________________________
>>>>>>> Fedora-commons-developers mailing list
>>>>>>> Fedora-commons-developers@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Storage Efficiency Calculator
>>>>>> This modeling tool is based on patent-pending intellectual property
>>>>>> that
>>>>>> has been used successfully in hundreds of IBM storage optimization
>>>>>> engage-
>>>>>> ments, worldwide. Store less, Store more with what you own, Move data
>>>>>> to
>>>>>> the right place. Try It Now!
>>>>>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>>>>> _______________________________________________
>>>>>> Fedora-commons-developers mailing list
>>>>>> Fedora-commons-developers@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Storage Efficiency Calculator
>>>>> This modeling tool is based on patent-pending intellectual property that
>>>>> has been used successfully in hundreds of IBM storage optimization
>>>>> engage-
>>>>> ments, worldwide. Store less, Store more with what you own, Move data
>>>>> to
>>>>> the right place. Try It Now!
>>>>> http://www.accelacomm.com/jaw/sfnl/114/51427378/
>>>>> _______________________________________________
>>>>> Fedora-commons-developers mailing list
>>>>> Fedora-commons-developers@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Got Input? Slashdot Needs You.
>>>> Take our quick survey online. Come on, we don't ask for help often.
>>>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>>>> http://p.sf.net/sfu/slashdot-survey
>>>> _______________________________________________
>>>> Fedora-commons-developers mailing list
>>>> Fedora-commons-developers@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Got Input? Slashdot Needs You.
>>> Take our quick survey online. Come on, we don't ask for help often.
>>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>>> http://p.sf.net/sfu/slashdot-survey
>>> _______________________________________________
>>> Fedora-commons-developers mailing list
>>> Fedora-commons-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>
>>
>> ------------------------------------------------------------------------------
>> Got Input? Slashdot Needs You.
>> Take our quick survey online. Come on, we don't ask for help often.
>> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
>> http://p.sf.net/sfu/slashdot-survey
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> Fedora-commons-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>>
>
> ------------------------------------------------------------------------------
> Got Input? Slashdot Needs You.
> Take our quick survey online. Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> Fedora-commons-developers mailing list
> Fedora-commons-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
