[cle-release-team] Kernel with OpenJDK 7

[Maurer, Christopher Wayne]

Did anything ever come of this?  We see intermittent test failures here
too.

Chris

On 2/23/12 3:16 AM, "David Horwitz" <david.horwitz at uct.ac.za> wrote:

>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(BaseCon
>>>tentService.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
>
>_______________________________________________
>cle-release-team mailing list
>cle-release-team at collab.sakaiproject.org
>http://collab.sakaiproject.org/mailman/listinfo/cle-release-team