2011-08-28 12 views
6

Eseguo un'applicazione Web basata su Spring Framework/SmartGWT, con ora un lavoro Quartz aggiunto. Il lavoro dovrebbe essere eseguito tutti i giorni alle 2 del mattino e preleva i vincitori da una tabella DB. Dal mio log vedo corre due volte, contemporaneamente a quanto pare, perché come si può vedere, i registri si sovrappongono:Il processo al quarzo viene eseguito due volte quando viene distribuito su tomcat 6/Ubuntu 10.04LTS

Generating winners of yesterday... 
Generating winners of yesterday... 
winning id's: 15 
done, mail queue is filled. 

winning id's: 18 
done, mail queue is filled. 

mio applicationContext.xml si presenta così:

<!-- initiates and calls the job --> 
<beans:bean id="GenerateWinnersAndFillMailingQueueJobDetail" class="org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean"> 
    <beans:property name="targetObject" ref="GenerateWinnersAndFillMailingQueueJobExecutor"/> 
    <beans:property name="targetMethod" value="execute"/> 
</beans:bean> 
<!-- here's where we use the Cron like scheduling expression  to define when the bean is run. --> 
<beans:bean id="GenerateWinnersAndFillMailingQueueJob" class="org.springframework.scheduling.quartz.CronTriggerBean"> 
    <beans:property name="jobDetail" ref="GenerateWinnersAndFillMailingQueueJobDetail"/> 
    <!-- run every morning at 2AM --> 
    <beans:property name="cronExpression" value="0 0 2 * * ?"/> 
</beans:bean> 
... another quartz jobs is defined here, omitted for clarity ... 
<beans:bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean"> 
    <beans:property name="triggers"> 
    <beans:list> 
     <beans:ref bean="GenerateWinnersAndFillMailingQueueJob"/> 
     <beans:ref bean="SendEmailsFromMailQueueJob"/> 
    </beans:list> 
    </beans:property> 
</beans:bean> 

io in realtà non vedere cosa c'è di sbagliato qui, è un caso d'uso piuttosto semplice. Quando eseguo il test localmente, sul server che viene fornito con la modalità di sviluppo GWT, funziona. Solo durante la distribuzione su Tomcat6 su Ubuntu 10.04 LTS, ottengo questo problema.

Qualche idea?

** modifica: dopo un suggerimento dai commenti, aumentando il livello del registro, sembra che Spring stia funzionando due volte. Il riavvio del server tomcat mostra che due sorgenti vengono istanziate, a circa 4 secondi di distanza.

2011-08-29 08:49:22,567 {ABSOLUTE} INFO XmlWebApplicationContext,Thread-9:1002 - Closing Root WebApplicationContext: startup date [Sun Aug 28 20:53:39 CEST 2011]; root of context hierarchy 
2011-08-29 08:49:22,569 {ABSOLUTE} INFO DefaultLifecycleProcessor,Thread-9:345 - Stopping beans in phase 2147483647 
2011-08-29 08:49:22,589 {ABSOLUTE} INFO QuartzScheduler,Thread-9:537 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED paused. 
2011-08-29 08:49:22,592 {ABSOLUTE} INFO DefaultListableBeanFactory,Thread-9:422 - Destroying singletons in org.s[email protected]12e14ebc: defining beans [org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,MerchantSimpleJsonWebservice,merchantDao,AdvertisementSimpleJsonWebservice,advertisementDao,ContactFormSubmitsSimpleJsonWebservice,contactFormSubmitsDao,PlayerCustomJsonWebservice,PlayerCustomJsonWebserviceImpl,submitSolutionDao,GenerateWinnersAndFillMailingQueueJobExecutor,GenerateWinnersAndFillMailingQueueJobDetail,GenerateWinnersAndFillMailingQueueJob,SendEmailsFromMailQueueJobExecutor,SendEmailsFromMailQueueJobDetail,SendEmailsFromMailQueueJob,org.springframework.scheduling.quartz.SchedulerFactoryBean#0,org.springframework.security.web.PortMapperImpl#0,org.springframework.security.web.context.HttpSessionSecurityContextRepository#0,org.springframework.security.authentication.ProviderManager#0,org.springframework.security.access.vote.AffirmativeBased#0,org.springframework.security.web.access.intercept.FilterSecurityInterceptor#0,org.springframework.security.web.access.DefaultWebInvocationPrivilegeEvaluator#0,org.springframework.security.authentication.AnonymousAuthenticationProvider#0,org.springframework.security.web.savedrequest.HttpSessionRequestCache#0,org.springframework.security.config.http.UserDetailsServiceInjectionBeanPostProcessor#0,org.springframework.security.filterChainProxy,sessionAuthenticationStrategy,sessionRegistry,propertyConfigurer,org.springframework.security.authentication.dao.DaoAuthenticationProvider#0,org.springframework.security.authentication.DefaultAuthenticationEventPublisher#0,org.springframework.security.authenticationManager,saltSource,dataSource,jdbcTemplate,passwordEncoder,jdbcUserService,loggerListener,formLoginFilter,authenticationEntryPoint,accessDeniedHandler,concurrencyFilter]; root of factory hierarchy 
2011-08-29 08:49:22,601 {ABSOLUTE} INFO SchedulerFactoryBean,Thread-9:760 - Shutting down Quartz Scheduler 
2011-08-29 08:49:22,601 {ABSOLUTE} INFO QuartzScheduler,Thread-9:616 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED shutting down. 
2011-08-29 08:49:22,602 {ABSOLUTE} INFO QuartzScheduler,Thread-9:537 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED paused. 
2011-08-29 08:49:22,603 {ABSOLUTE} INFO QuartzScheduler,Thread-9:688 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED shutdown complete. 
2011-08-29 08:49:22,882 {ABSOLUTE} INFO XmlWebApplicationContext,Thread-9:1002 - Closing Root WebApplicationContext: startup date [Sun Aug 28 20:53:34 CEST 2011]; root of context hierarchy 
2011-08-29 08:49:22,883 {ABSOLUTE} INFO DefaultLifecycleProcessor,Thread-9:345 - Stopping beans in phase 2147483647 
2011-08-29 08:49:22,903 {ABSOLUTE} INFO QuartzScheduler,Thread-9:537 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED paused. 
2011-08-29 08:49:22,904 {ABSOLUTE} INFO DefaultListableBeanFactory,Thread-9:422 - Destroying singletons in org.s[email protected]402fb002: defining beans [org.springframework.context.annotation.internalConfigurationAnnotationProcessor,org.springframework.context.annotation.internalAutowiredAnnotationProcessor,org.springframework.context.annotation.internalRequiredAnnotationProcessor,org.springframework.context.annotation.internalCommonAnnotationProcessor,MerchantSimpleJsonWebservice,merchantDao,AdvertisementSimpleJsonWebservice,advertisementDao,ContactFormSubmitsSimpleJsonWebservice,contactFormSubmitsDao,PlayerCustomJsonWebservice,PlayerCustomJsonWebserviceImpl,submitSolutionDao,GenerateWinnersAndFillMailingQueueJobExecutor,GenerateWinnersAndFillMailingQueueJobDetail,GenerateWinnersAndFillMailingQueueJob,SendEmailsFromMailQueueJobExecutor,SendEmailsFromMailQueueJobDetail,SendEmailsFromMailQueueJob,org.springframework.scheduling.quartz.SchedulerFactoryBean#0,org.springframework.security.web.PortMapperImpl#0,org.springframework.security.web.context.HttpSessionSecurityContextRepository#0,org.springframework.security.authentication.ProviderManager#0,org.springframework.security.access.vote.AffirmativeBased#0,org.springframework.security.web.access.intercept.FilterSecurityInterceptor#0,org.springframework.security.web.access.DefaultWebInvocationPrivilegeEvaluator#0,org.springframework.security.authentication.AnonymousAuthenticationProvider#0,org.springframework.security.web.savedrequest.HttpSessionRequestCache#0,org.springframework.security.config.http.UserDetailsServiceInjectionBeanPostProcessor#0,org.springframework.security.filterChainProxy,sessionAuthenticationStrategy,sessionRegistry,propertyConfigurer,org.springframework.security.authentication.dao.DaoAuthenticationProvider#0,org.springframework.security.authentication.DefaultAuthenticationEventPublisher#0,org.springframework.security.authenticationManager,saltSource,dataSource,jdbcTemplate,passwordEncoder,jdbcUserService,loggerListener,formLoginFilter,authenticationEntryPoint,accessDeniedHandler,concurrencyFilter]; root of factory hierarchy 
2011-08-29 08:49:22,913 {ABSOLUTE} INFO SchedulerFactoryBean,Thread-9:760 - Shutting down Quartz Scheduler 
2011-08-29 08:49:22,914 {ABSOLUTE} INFO QuartzScheduler,Thread-9:616 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED shutting down. 
2011-08-29 08:49:22,914 {ABSOLUTE} INFO QuartzScheduler,Thread-9:537 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED paused. 
2011-08-29 08:49:22,915 {ABSOLUTE} INFO QuartzScheduler,Thread-9:688 - Scheduler org.springframework.scheduling.quartz.SchedulerFactoryBean#0_$_NON_CLUSTERED shutdown complete. 
2011-08-29 08:49:26,484 {ABSOLUTE} INFO ContextLoader,main:187 - Root WebApplicationContext: initialization started 

Più tardi, due istanze di primavera sembrano essere avviato:

2011-08-29 08:49:26,484 {ABSOLUTE} INFO ContextLoader,main:187 - Root WebApplicationContext: initialization started 
... 
2011-08-29 08:49:31,221 {ABSOLUTE} INFO ContextLoader,main:187 - Root WebApplicationContext: initialization started 

Che cosa può causare questo, e ciò che è da fare?

+0

Potrebbe essere una buona idea aumentare il livello di registrazione del quarzo un po 'per vedere se il lavoro viene effettivamente pianificato due volte per l'esecuzione. – fvu

+0

Grazie. Ho messo il livello di log primaverile per il debug, e sembra che le spring run funzionino due volte (ma è l'unica app distribuita)! O la molla viene eseguita due volte, OPPURE il bean del programma di pianificazione del quarzo viene istanziato due volte. Ho inserito il registro nella domanda sopra –

+0

Ho osservato questo comportamento anche senza quarzo. Il contesto primaverile veniva caricato due volte ogni volta che eseguivo l'app su Tomcat (anche su Windows da netbeans). – kunal

risposta

7

Ho risolto il problema, non solo il quarzo era in esecuzione due volte, ma la mia app è stata distribuita due volte. Ciò è dovuto a quanto segue nei documenti Tomcat:

Quando si utilizza la distribuzione automatica, il file docBase definito da un file di contesto XML deve trovarsi all'esterno della directory appBase. In caso contrario, si potrebbero incontrare difficoltà nell'implementazione dell'applicazione Web o l'applicazione potrebbe essere distribuita due volte. L'attributo deployIgnore può essere utilizzato per evitare questa situazione.

Infine, si noti che se si definiscono i contesti in modo esplicito in server.xml, è consigliabile disattivare la distribuzione dell'applicazione automatica o specificare attentamente deployIgnore. In caso contrario, le applicazioni Web verranno distribuite ciascuna due volte e ciò potrebbe causare problemi alle applicazioni.

Ho seguito un tutorial su come ottenere il funzionamento di mod_jk e this tutorial conteneva tale difetto.

0

Alla fine hai più applicazioni in esecuzione all'interno di un'istanza Tomcat sul tuo computer Ubunut? Penso di ricordare che Quartz ha un codice statico, che condividerebbe con tutte le applicazioni in una VM Java.

+0

Grazie per la risposta. E sì, ho appena capito che non solo il quarzo era in esecuzione due volte, ma l'intera app è stata distribuita due volte. Vedi la mia risposta qui sotto. –

3

Per me, la distribuzione automatica era il problema, e per disabilitarla ho dovuto specificare i seguenti attributi nella ospite elemento a mio server.xml:

deployOnStartup="false" 
autoDeploy="false" 

Quindi il mio elemento ospite sembrava questo:

<Host name="localhost" 
     deployOnStartup="false" 
     appBase="webapps" 
     unpackWARs="false" 
     autoDeploy="false"> 

ho trovato this post in dettaglio il problema in un modo diverso che mi ha aiutato a risolvere questo problema.

Problemi correlati