Sem treinador Fios da mola de quartzo Websphere hibernação

Question

Parece que a nossa implementação de usar Quartz - JDBCJobStore juntamente com Spring, Hibernate e Websphere está jogando tópicos não gerenciados.

Eu tenho feito algumas leituras e encontrou um artigo de tecnologia da IBM afirmando que o uso de quartzo com mola fará isso. Eles fazem a sugestão de usar CommnonJ para abordar esta questão.

Tenho feito algumas pesquisas adicionais e os únicos exemplos que eu tenho visto até agora todo o negócio com o plano JobStore velho que não está em um banco de dados.

Então, eu queria saber se alguém tem um exemplo da solução para este problema.

Graças

Answer 1

Temos uma solução de trabalho para este (dois, na verdade).

1) Alter do código-fonte de quartzo de usar um fio daemon WorkManager para o thread principal planificador. Ele funciona, mas exige a mudança de litros. Nós não usar isso, porém, uma vez que não queria manter uma versão hackeada do quartzo. (Isso me lembra, eu estava indo para enviá-lo para o projeto, mas esqueci completamente)

2) Criar um WorkManagerThreadPool para ser usado como o quartzo threadpool. Implementar a interface para o ThreadPool de quartzo, para que cada tarefa que é desencadeada dentro de quartzo é envolto em um objeto de trabalho CommonJ que irá então ser agendado na WorkManager. A chave é que o WorkManager na WorkManagerThreadPool tem de ser inicializado antes do planejador é iniciado, a partir de uma thread Java EE (como inicialização servlet). O WorkManagerThreadPool deve, então, criar um thread daemon que irá lidar com todas as tarefas agendadas por criar e programar os novos objetos de trabalho. Desta forma, o programador (em seu próprio segmento) está passando as tarefas a um segmento gerenciado (o daemon de Trabalho).

não é simples, e, infelizmente, eu não tenho código prontamente disponível para incluir.

Answer 2

Como adicionar outra resposta para o segmento, desde que eu encontrei uma solução para este, finalmente.

O meu ambiente :. ERA 8.5.5, 1.8.5 Quartz, não Primavera

O problema i teve foi o (acima indicado) rosca não gerenciado causando uma NamingException de ctx.lookup(myJndiUrl), que estava trabalhando em vez corretamente em outros servidores de aplicações (JBoss, Weblogic); na verdade, Webpshere estava disparando um "incidente" com a seguinte mensagem:

javax.naming.ConfigurationException: Operação A JNDI em um "java:" nome não pode ser concluída porque o tempo de execução do servidor não é capaz de associar fio da operação com qualquer componente da aplicação J2EE. Essa condição pode ocorrer quando o cliente JNDI usando o "java:" nome não é executado no thread de um pedido de aplicação de servidor. Certifique-se que uma aplicação J2EE não executa operações JNDI em "java:" nomes dentro de blocos de código estático ou em tópicos criados por essa aplicação J2EE. Esse código não necessariamente executado no thread de um pedido de aplicação de servidor e, portanto, não é suportado por operações JNDI em "java:". Nomes

As seguintes etapas resolveu o problema:

1) atualizado para quartzo 1.8.6 (nenhuma alteração de código), apenas maven pom

2) aditado o seguinte dep ao classpath (no meu caso, a orelha do / lib pasta), para fazer o novo WorkManagerThreadExecutor disponível

<dependency>
  <groupId>org.quartz-scheduler</groupId>
  <artifactId>quartz-commonj</artifactId>
  <version>1.8.6</version>
</dependency>

Nota: em RQ-113 ou a documentação oficial Quartz 1.x 2.x não há nenhuma menção sobre como ativar essa correção.

3) adicionado o seguinte para quartz.properties ( "wm / default" foi o JNDI do DefaultWorkManager já configurado na minha ERA 8.5.5, veja Recursos -> AsynchronousBeans -> WorkManagers no WAS console):

org.quartz.threadExecutor.class=org.quartz.custom.WorkManagerThreadExecutor
org.quartz.threadExecutor.workManagerName=wm/default

Nota: certa classe é org.quartz costume .WorkManagerThreadExecutor para quartz-scheduler-1.8.6 (testado), ou org.quartz <.. strong> CommonJ .WorkManagerThreadExecutor de 2.1.1 em (não testado, mas comprovada na real frascos de quartzo-CommonJ em repos do Maven)

4) foi movida a lookup JNDI no construtor vazio do trabalho de quartzo (graças a o m_klovre "thread fora do recipiente J2EE" ); isto é, o construtor estava sendo invocado pela reflexão (método newInstance()) do mesmo contexto J2EE da minha candidatura, e tinha acesso a namespace java:global, enquanto o método execute(JobExecutionContext) ainda estava correndo em um contexto mais pobres, o que estava faltando todos os meus da aplicação EJBs

Espero que isso ajude.

Ps. como uma referência, você pode encontrar aqui um exemplo dos quartz.properties arquivo que eu estava usando acima

Answer 3

Verifique este artigo: http://www.ibm.com/developerworks/websphere/techjournal/ 0609_alcott / 0609_alcott.html

basicamente, defina a propriedade taskExecutor em SchedulerFactoryBean usar um org.springframework.scheduling.commonj.WorkManager TaskExecutor que usará recipiente threads gerenciados.

Answer 4

Apenas uma nota: Ligação QUARTZ-708 do acima não é mais válido. Esta nova edição (em uma nova Jira) parece estar a resolver o problema: http://jira.terracotta.org/jira/browse/QTZ-113 (fixVersion = 1.8.6, 2.0.2)

Answer 5

Você pode verificar o link abaixo JIRA levantada em quartzo em relação a este.

http://jira.opensymphony.com/browse/QUARTZ-708

Isto tem a implementação WebSphereThreadPool exigido que pode ser usado com as mudanças na quartz.properties como mencionado para atender às suas necessidades. Espero que isso ajude.

Saudações, Siva

Answer 6

Você terá que pools de threads gerenciados uso do WebSphere. Você pode fazer isso através de primavera e CommonJ. CommonJ lata tem um executor de tarefas que irá criar tópicos gerenciados. Você ainda pode usar uma referência a um recurso fio jndi gerenciado. Você pode, em seguida, injetar o executor de tarefas CommonJ no Quartz SchedulerFactoryBean baseada Primavera.

Por favor, veja http://open.bekk.no/boss/spring -scheduling-in-websphere "com CommonJ Quartz" seção / e de rolagem para obter mais detalhes.

Answer 7

A proposta da PaoloC para WAS85 ans Quartz 1.8.6 também funciona em WAS80 (e Quartz 1.8.6) e não precisa de Primavera. (Na minha configuração Primavera 2.5.5 está presente, mas não em uso nesse contexto.)

Dessa forma, eu era capaz de substituir SimpleJobFactory por minha própria variante, usando um InjectionHelper aplicar CDI em cada trabalho recém-criado. obras de injecção para ambas @EJB (com JNDI lookup da interface de negócios remota EJB anotada) e @Inject (com JNDI lookup do CDI BeanManager usando um novo InitialContext primeiro, e depois usar este BM recém buscada para procurar o próprio feijão CDI).

Obrigado PaoloC para essa resposta! (Espero que este texto irá aparecer como uma "resposta a PaoloC" e não como uma resposta ao tópico principal. Encontrado nenhuma maneira de diferenciar entre estes.)

Answer 8

Eu encontrei recentemente este problema. Praticamente você precisa:

1. Implementar pool de threads, delegando trabalho para Websphere Work Manager. (Quartz fornece apenas SimpleThreadPool que os trabalhos de execução em threads não gerenciados). Diga quartzo para usar esse pool de threads por propriedade org.quartz.threadPool.class
2. Diga quartzo para uso WorkManagerThreadExecutor (ou implementar um personalizado) pela propriedade org.quartz.threadExecutor.class
3. A paciência com pesados ??recipientes web legados mordeu:)

Aqui está github demonstração de usar Quartz com Websphere (e também Tomcat).

Espero que ajude alguém ..