[Building Sakai] Tomcat not shutting down properly

John Bush john.bush at rsmart.com
Sat Aug 18 16:04:24 PDT 2012


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"



-- 
John Bush
602-490-0470


More information about the sakai-dev mailing list