[Building Sakai] Tomcat not shutting down properly

Brian Baillargeon bbailla2 at uwo.ca
Fri Aug 24 07:33:58 PDT 2012 

I'm using all the same beans as before, I'm just grabbing them with 
ComponentManager now. So, if these annotations work for you, I'm 
thinking the project's architecture could have something to do with it. 
Do you inject beans into spring-mvc controllers?

On 12-08-23 05:28 PM, Steve Swinsburg wrote:
> I use these annotations extensively in my applications and haven't had these issues. It might be with the specific beans, not the wiring method, perhaps.
>
> cheers,
> Steve
>
>
> On 24/08/2012, at 6:51 AM, Brian Baillargeon <bbailla2 at uwo.ca> wrote:
>
>> After days of commenting out sections of code, starting and stopping
>> tomcat to check for lingering threads, I finally resolved it!
>>
>> Somehow the @Autowired and @Resource annotations were causing this.
>> I removed all such annotations - they were only present in
>> BaseCertificateController.
>> While avoiding annotations, I tried to find a way to inject beans into
>> BaseCertificateController, but I gave up because it's a spring-mvc
>> controller and that complicated things on the xml side.
>> So I simply removed the bean setters and getters in
>> BaseCertificateController and used ComponentManager.get() calls to get
>> our beans back.
>>
>> I grepped my Sakai source directory and didn't see any instances of
>> @Autowired or @Resource outside of this tool. So, I must ask - is there
>> a known issue with these annotations in the context of Sakai? Are there
>> any configurations where these annotations don't cause lingering threads
>> after tomcat shutdown? Is this documented?
>>
>> Thanks,
>> Brian
>>
>> On 12-08-20 10:38 AM, Brian Baillargeon wrote:
>>> I applied the patch, but I'm afraid the thread still lingers after
>>> shutdown. If it matters, we use tomcat 5.5. I'll keep investigating why
>>> the CertificateService bean seems to be the deciding factor
>>>
>>> On 12-08-18 07:04 PM, John Bush wrote:
>>>> You might want to try patching in my lastest commit from this morning,
>>>> in https://source.sakaiproject.org/contrib/rsmart/certification/
>>>>
>>>> I'm not sure its related or not, but we noticed some intermittent
>>>> classpath problems on tomcat7 in the cert tool.  We eventually
>>>> narrowed it down to the use of interfaces in the hibernate model.
>>>> There were a few entities that had some mistakes in the hbms.  These
>>>> sorts of weird classpath issues code cause problems at shutdown, it
>>>> might be worth just giving it a try.
>>>>
>>>> On Fri, Aug 17, 2012 at 3:02 PM, Brian Baillargeon <bbailla2 at uwo.ca> wrote:
>>>>> I'm revisiting this issue as we're going to need the certifications tool
>>>>> soon.
>>>>>
>>>>> Recap - when certifications is deployed, a thread lingers after shutting
>>>>> down tomcat (James is disabled)
>>>>>
>>>>> We've been working on certification in our msub
>>>>> (https://source.sakaiproject.org/svn/msub/uwo.ca/certification/trunk/)
>>>>> But this can be reproduced on rsmart's version in contrib.
>>>>>
>>>>> I've been trying to isolate the problem, and I found that if you remove
>>>>> the beans:
>>>>> com.rsmart.certification.api.CertificateService
>>>>> and
>>>>> com.rsmart.certification.api.CertificateService.wrapped
>>>>> from
>>>>> ./pack/src/webapp/WEB-INF/components.xml
>>>>> ie. comment the beans out and remove any references to them from other
>>>>> beans' properties
>>>>> -build, deploy, startup, shutdown (all steps are successful)
>>>>> -'pgrep java' shows no threads
>>>>>
>>>>> So I figured the culprits are either
>>>>> com.rsmart.certification.api.CertificateService or
>>>>> com.rsmart.certification.api.CertificateService.wrapped
>>>>>
>>>>> Then I reverted components.xml
>>>>>
>>>>> To be sure that the lingering thread wasn't caused by java code or
>>>>> org.springframework.transaction.interceptor.TransactionProxyFactoryBean, I:
>>>>> -removed the bean definition for
>>>>> com.rsmart.certification.api.CertificateService.wrapped
>>>>> -replaced com.rsmart.certification.api.CertificateService with:
>>>>>
>>>>>        <bean id="com.rsmart.certification.api.CertificateService"
>>>>>              class="com.rsmart.certification.impl.hibernate.CertificateServiceHibernateImpl"
>>>>>              init-method="init">
>>>>>            <property name="sessionFactory" ref="org.sakaiproject.springframework.orm.hibernate.GlobalSessionFactory"/>
>>>>>            <!--<property name="documentTemplateService" ref="com.rsmart.certification.api.DocumentTemplateService"/>
>>>>>            <property name="contentHostingService" ref="org.sakaiproject.content.api.ContentHostingService"/>
>>>>>            <property name="toolManager" ref="org.sakaiproject.tool.api.ToolManager"/>
>>>>>            <property name="sessionManager" ref="org.sakaiproject.tool.api.SessionManager"/>
>>>>>            <property name="securityService" ref="org.sakaiproject.authz.api.SecurityService"/>
>>>>>            <property name="adminUser" value="admin"/>
>>>>>            <property name="userDirectoryService" ref="org.sakaiproject.user.api.UserDirectoryService"/>
>>>>>            <property name="templateDirectory" value="${sakai.home}/templates"/>
>>>>>            <property name="shortenedUrlService" ref="org.sakaiproject.shortenedurl.api.ShortenedUrlService"/>-->
>>>>>        </bean>
>>>>>
>>>>>        -(I believe HibernateDaoSupport will complain without a sessionFactory)
>>>>> -I replaced CertificateServiceHibernateImpl.java with a simple class
>>>>> that extends HibernateDaoSupport and implements CertificateService such
>>>>> that all its implemented methods were empty or returned null.
>>>>> -build, deploy, startup, shutdown (all steps are successful)
>>>>> -'pgrep java' shows a lingering thread
>>>>>
>>>>> So, it seems to me that the existence of the CertificateService bean
>>>>> (regardless of whether the corresponding .java file has any executable
>>>>> code) decides whether tomcat can or can't shut down properly, but I
>>>>> can't find anything special about the bean.
>>>>>
>>>>> Does that all make sense? I'm new to spring so am I missing something
>>>>> that can be affected by the existence of this bean? Can it get picked up
>>>>> somewhere even if you don't add it as a property to another bean?
>>>>>
>>>>> Thanks,
>>>>> Brian
>>>>>
>>>>> On 12-03-28 12:42 PM, Brian Jones wrote:
>>>>>> We're not using many contrib tools, but they are as follows:
>>>>>>
>>>>>> - contentreview-impl
>>>>>> (https://source.sakaiproject.org/contrib/turnitin/tags/content-review-0.7)
>>>>>> - EntityBrowser (https://source.sakaiproject.org/contrib/asu/EntityBrowser)
>>>>>> - certification
>>>>>> (https://source.sakaiproject.org/contrib/rsmart/certification/)
>>>>>> - rsmart-common
>>>>>> (https://source.sakaiproject.org/contrib/rsmart/rsmart-common/)
>>>>>> - sakora (https://source.sakaiproject.org/contrib/unicon/sakora-csv/trunk)
>>>>>>
>>>>>> FYI, we only experienced the problem AFTER deploying Rsmart's certification
>>>>>> tool.
>>>>>> And we're based off 2.8.x
>>>>>>
>>>>>> Brian Jones
>>>>>> Applications Development
>>>>>> Information Technology Services
>>>>>> Support Services Building, Room 4326
>>>>>> University of Western Ontario
>>>>>> (519) 661-2111 x86969
>>>>>> bjones86 at uwo.ca
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Seth Theriault [mailto:slt at columbia.edu]
>>>>>> Sent: Wednesday, March 28, 2012 12:38 PM
>>>>>> To: Brian Jones
>>>>>> Cc: mike_jennings at unc.edu; 'Aaron Zeckoski';
>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>> Subject: Re: [Building Sakai] Tomcat not shutting down properly
>>>>>>
>>>>>> Brian Jones wrote:
>>>>>>
>>>>>>> Thanks to everyone for doing some heavy duty testing on this issue.
>>>>>>>
>>>>>>> However, I don't believe gradebook2 is the root cause, as we don't use
>>>>>>> gradebook2 at Western University at all, but we still experience the
>>>>>> issue.
>>>>>>
>>>>>> What other contrib or additional tools are you running? We are looking more
>>>>>> closely at GB2 because it was in the common Columbia-UNC overlap.
>>>>>>
>>>>>> It's also possible that a similar problem affects other tools.
>>>>>>
>>>>>> Seth
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sakai-dev mailing list
>>>>>> sakai-dev at collab.sakaiproject.org
>>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>>
>>>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>> _______________________________________________
>>>>> sakai-dev mailing list
>>>>> sakai-dev at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>>
>>>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

More information about the sakai-dev mailing list