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
