[Building Sakai] [cle-release-team] Kernel with OpenJDK 7

[Raymond Naseef]

I checked Sakai 2.9.0 (trunk) and found cause of the error in this thread
(from February 22, 2012): dependencies among test methods in 1 class!!!
 The problem is intermittent as the problem is based on what order each of
the test class's methods are run [i.e., start -> testA() -> testB() OK,
start -> testB() -> testA() FAILS].  I believe such dependency is
considered improper for Sakai Project, correct?

DETAILS:
  The failing test method:
 ContentHostingServiceTest#testUtfFolders
    (error on line 198 in trunk -- 2.9.0).
  The need:
 ContentHostingService#addCollection(<utfId>)
  This works after running test method:
ContentHostingServiceTest#testSaveRetriveFolder()

I recommend the following fix.  Please let me know if you would like me to
do some or all of these.

1. Change ID of collection in testUtfFolders()
2. Calling ContentHostingService.addCollection() in testUtfFolders() to
create its collection
<optional> 3. Remove collection from the cache at end of testUtfFolders()
<optional> 4. Changing ContentHostingServiceTest#testDeleteResource() to
not log the expected "IdUnusedException"

ERROR DETAILS:
Sakai CLE 2.9.0 sakai-src-trunk downloaded 2013-01-25:

org.sakaiproject.exception.IdUnusedException id: /admin/??????????/
    at
org.sakaiproject.content.impl.BaseContentService.checkCollection(BaseContentService.java:2121)
    at
org.sakaiproject.content.impl.BaseContentService.addResource(BaseContentService.java:3257)
    at
org.sakaiproject.content.impl.test.ContentHostingServiceTest.testUtfFolders(ContentHostingServiceTest.java:198)


All the best,
Ray


>There's also the thorny issue that the use of threadloacal in a service
>is less than ideal and can lead to memory leaks (and the CHS ones have
>in the past)
>
>D
>
On 02/23/2012 04:59 AM, Noah Botimer wrote:
>> I would say that this thread is sufficiently technical that it belongs
on the dev list. But to be on topic...
>>
>> I've just been looking at caching and was noticing the ThreadLocals
dropping (it seemed, at least) values with no special characters. The puts
were issued and subsequent gets in the same thread were falling through. An
example is in a simple getUserByEid() call for admin. The Ehcache set up
through the MemoryService (second layer; maybe the first is unneeded in
this case) was catching all gets in the "call cache".
>>
>> This is unrelated to OpenJDK or JDK7, as I am using sun-java6-jdk on
Ubuntu 11.10. So, there may be a couple of things to pull apart here:
general ThreadLocal behavior on standard infrastructure and JDK7 effect on
ThreadLocal behavior / UTF8 strings / queries.
>>
>> Thanks,
>> -Noah
>>
>> On Feb 22, 2012, at 9:43 PM, Earle Nietzel wrote:
>>
>>> Sam,
>>>
>>> I now understand why this test is failing but I am not sure how to fix
it:
>>>
>>> It is all related to this method in BaseContentService:
>>>
>>> protected ContentCollection findCollection(String id) throws
TypeException
>>> {
>>> ContentCollection collection = null;
>>> try
>>> {
>>> collection = (ContentCollection)
>>> threadLocalManager.get("findCollection@" + id);
>>>
>>> This returns null since it doesn't find the key in
>>> ThreadLocalComponent bindings map.
>>> WARN ThreadLocalComponent:183 - get: key not found:
>>> findCollection@/admin/??????????/
>>>
>>> }
>>> catch(ClassCastException e)
>>> {
>>> throw new TypeException(id);
>>> }
>>>
>>> if(collection == null)
>>> {
>>> collection = m_storage.getCollection(id);
>>>
>>> Then it tries to perform a lookup from storage but this also fails
>>> because ThreadLocalComponent does not contain the following key.
>>> WARN ThreadLocalComponent:183 - get: key not found:
>>> sqlService:transaction_connection
>>>
>>> if(collection != null)
>>> {
>>> threadLocalManager.set("findCollection@" + id, collection); // new
>>> BaseCollectionEdit(collection));
>>> }
>>> }
>>> else
>>> {
>>> collection = new BaseCollectionEdit(collection);
>>> }
>>>
>>> return collection;
>>>
>>> } // findCollection
>>>
>>> Then the following exception occurs:
>>> org.sakaiproject.exception.IdUnusedException id=/admin/??????????/
>>> at
org.sakaiproject.content.impl.BaseContentService.checkCollection(BaseContentService.java:2230)
>>>
>>> To me it looks as though ThreadLocalComponent did not get setup
properly.
>>>
>>> Funny part about all of this is I cannot reproduce this in the
>>> debugger remotely connected to maven surefire
>>>
>>> mvn test -Dtest=ContentHostingServiceTest -DfailIfNoTests=false
>>> -Dmaven.surefire.debug
>>>
>>> but when running without debugging it happens almost every time:
>>>
>>> mvn test -Dtest=ContentHostingServiceTest -DfailIfNoTests=false
>>>
>>> Suggestions?
>>>
>>> Earle
>>>
>>> On Wed, Feb 22, 2012 at 12:27 AM, Earle Nietzel <earle.nietzel at
gmail.com> wrote:
>>>> Hey Sam,
>>>>
>>>> I was able to get 2/3 tests fixed. The last one is taking a little
>>>> longer since I can't even reproduce in eclipse.
>>>>
>>>> Only happens when building from the console.
>>>>
>>>> Here is the failing test from kernel-impl:
>>>> ContentHostingServiceTest.testUtfFolders
>>>>
>>>> You can run it with:
>>>> mvn test -Dtest=ContentHostingServiceTest -DfailIfNoTests=false
>>>>
>>>> I will continue to look at it,
>>>> Earle
>>>>
>>>> On Tue, Feb 21, 2012 at 4:51 PM, Sam Ottenhoff <ottenhoff at
longsight.com> wrote:
>>>>> Cool, thanks.
>>>>>
>>>>> --Sam
>>>>>
>>>>>
>>>>> On Tue, Feb 21, 2012 at 4:49 PM, Earle Nietzel <earle.nietzel at
gmail.com>
>>>>> wrote:
>>>>>> I will investigate, thanks for pointing it out.
>>>>>>
>>>>>> Earle
>>>>>>
>>>>>> On Tue, Feb 21, 2012 at 3:38 PM, Sam Ottenhoff <ottenhoff at
longsight.com>
>>>>>> wrote:
>>>>>>> What about tests on the kernel?  My local Jenkins is reporting a
test
>>>>>>> failure in org.sakaiproject.kernel:sakai-kernel-impl
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 21, 2012 at 2:46 PM, Earle Nietzel <earle.nietzel at
gmail.com>
>>>>>>> wrote:
>>>>>>>> Yes everything is compiling as expected by changing the version in
bot
>>>>>>>> the master and kernel poms. I will add some more notes to the JIRA.
>>>>>>>>
>>>>>>>> Tested with OpenJDK 6 and 7.
>>>>>>>>
>>>>>>>> Earle
>>>>>>>>
>>>>>>>> On Tue, Feb 21, 2012 at 2:12 PM, Sam Ottenhoff
>>>>>>>> <ottenhoff at longsight.com>
>>>>>>>> wrote:
>>>>>>>>> Hey Earle,
>>>>>>>>>
>>>>>>>>> Thanks for all of your work on compilation issues. It's much
>>>>>>>>> appreciated.
>>>>>>>>> Have you been able to compile the kernel against OpenJDK 7?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sam
>>>>>>>
>>>>>
>>> _______________________________________________
>>> cle-release-team mailing list
>>> cle-release-team at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130126/91728a1c/attachment.html