[Building Sakai] Tomcat not shutting down properly

Steve Swinsburg steve.swinsburg at gmail.com
Thu Aug 23 14:28:49 PDT 2012 

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