2012-08-14 7 views
8

Nie jestem do końca pewien, czy jest to bardziej kwestia Openbravo, czy raczej problem kwarcowy, ale mamy pewne ręczne procesy, które są uruchamiane w harmonogramach przez obiekty Openbravo ProcessRequest (OB v2.50MP24), ale wygląda na to, że procesy są uruchamiane dwukrotnie, w tym samym czasie. Openbravo rozszerza platformę kwarcową o ich harmonogram. Starałem się rozwiązać ten problem na własną rękę poprzez zapewnienie, że moje zajęcia procesowe rozszerzyć tę klasę:Zaplanowane procesy uruchomione dwa razy jednocześnie w Openbravo (przy użyciu kwarcu)

import java.util.List; 

import org.openbravo.dal.service.OBDal; 
import org.openbravo.model.ad.ui.ProcessRequest; 
import org.openbravo.scheduling.ProcessBundle; 
import org.openbravo.service.db.DalBaseProcess; 

public abstract class RBDDalProcess extends DalBaseProcess { 

    @Override 
    protected void doExecute(ProcessBundle bundle) throws Exception { 
     org.quartz.Scheduler sched = org.openbravo.scheduling.OBScheduler 
       .getInstance().getScheduler(); 
     int runCount = 0; 
     synchronized (sched) { 
      List<org.quartz.JobExecutionContext> currentlyExecutingJobs = (List<org.quartz.JobExecutionContext>) sched 
        .getCurrentlyExecutingJobs(); 
      for (org.quartz.JobExecutionContext jec : currentlyExecutingJobs) { 
       ProcessRequest processRequest = OBDal.getInstance().get(
         ProcessRequest.class, jec.getJobDetail().getName()); 
       if (processRequest == null) 
        continue; 
       String processClass = processRequest.getProcess() 
         .getJavaClassName(); 
       if (bundle.getProcessClass().getCanonicalName() 
         .equals(processClass)) { 
        runCount++; 
       } 
      } 
     } 

     if (runCount > 1) { 
      System.out.println("Process " 
        + bundle.getProcessClass().getSimpleName() 
        + " is already running. Cancelling."); 
      return; 
     } 

     doRun(bundle); 
    } 

    protected abstract void doRun(ProcessBundle bundle); 

} 

to działało dobrze, kiedy testowano żądając proces uruchomić natychmiast dwa razy w tym samym czasie. Jeden z nich został anulowany. Jednak nie działa on na zaplanowanych procesach. Mam skonfigurowaną funkcję S.o.p, aby rejestrować po rozpoczęciu procesów, a przeglądanie dzienników pokazuje każdą linię danych wyjściowych dwukrotnie, a każdą linię zaraz po drugiej.

Podejrzewam podejrzenie, że dzieje się tak dlatego, że procesy przebiegają w dwóch zupełnie różnych wątkach, które nie znają się nawzajem na swoich procesach, nie jestem jednak pewien, w jaki sposób zweryfikować swoje podejrzenia lub jeśli jestem poprawne, co z tym zrobić. Już sprawdziłem, że istnieje tylko jedno wystąpienie każdego z obiektów ProcessRequest przechowywanych w bazie danych.

Czy ktoś inny doświadczył tego, wie, dlaczego może działać dwa razy, lub wie, co mogę zrobić, aby zapobiec ich jednoczesnemu uruchomieniu?

+0

Czy próbowałeś sprawdzić zrzut wątku podczas debugowania (mam na myśli, które wątki są uruchomione)? – kamaci

+0

kamaci, chciałbym spróbować, ale ten sam scenariusz nie dzieje się na mojej maszynie programistycznej; dzieje się to tylko na serwerze produkcyjnym, którego nie wiem jak debugować wątki, ponieważ jest dostęp tylko do wiersza poleceń (więc nie mogę użyć czegoś takiego jak VisualVM). –

+0

Proponuję użyć logowania i zapisania go w pliku dziennika. Może może nam coś pokazać? Z drugiej strony, jeśli jest to inna maszyna, a nie twoja i inni programiści też jej używają, pamiętaj, że nikt nie dociera do tego komputera i nie robi testu podczas testowania. – kamaci

Odpowiedz

6

najczęstszych przyczyn podwójnym wykonywania pracy są następujące:

edycja:

  • Aplikacja jest wdrożony w środowisku klastrowym i nie skonfigurowano Quartz uruchomić w środowisko klastrowe.
  • Twoja aplikacja zostanie wdrożona więcej niż raz. Istnieje wiele przypadków, w których aplikacja jest wdrażana dwukrotnie, szczególnie na serwerze Tomcat. W konsekwencji QuartzInitializerListener jest wywoływany dwukrotnie, a zadania są wykonywane dwukrotnie. W przypadku korzystania z serwera Tomcat i jawnego definiowania kontekstów w pliku server.xml, należy wyłączyć automatyczne wdrażanie aplikacji lub określić opcję wdrażajIgnore. Zarówno zestaw autoDeploy ustawiony na true, jak i istnienie elementu kontekstowego w pliku server.xml, powodują dwukrotne wdrożenie aplikacji. Ustaw autoDeploy na false lub usuń element context z pliku server.xml.
  • Twoja aplikacja została ponownie wdrożona bez nieplanowania bieżących procesów.

Mam nadzieję, że ci to pomoże.

+0

Niestety kontekst nie jest jawnie zdefiniowany w pliku server.xml, a my nie jesteśmy w środowisku klastrowym. –

+0

OK, więc wygląda na to, że odkrywanie problemów z * nie wdrożeniem *, ale * ponownym rozmieszczeniem * po kompilacji, doprowadziło mnie do stwierdzenia, że ​​w jakiś sposób program planujący dostaje "nietypowy" i dwa razy uruchamia zaplanowane procesy, ale jeśli nie zajmuję się procesami i przestawiam je ponownie procesy są uruchamiane tylko raz. Wydaje mi się to "tanio" do zrobienia, ale będzie to musiało zrobić na teraz, a ponieważ twoja odpowiedź doprowadziła mnie do tego odkrycia, Tolis, pójdę do przodu i dam ci nagrodę. :) –

+0

Dzięki Anthony :) –

1

Kwarc wykorzystuje pulę wątków do wykonania zadań. Tak więc, jak podejrzewasz, RBDDalProcess prawdopodobnie będzie mieć osobne instancje a w osobnym wątku, a sprawdzenie licznika nie powiedzie się.

Jedną rzeczą, jaką można zrobić, to listy zadań zapisanych w harmonogramie (można dostać Harmonogram używając API OB jak: OBScheduler.getScheduler()):

// enumerate each job group 
for(String group: sched.getJobGroupNames()) { 
    // enumerate each job in group 
    for(JobKey jobKey : sched.getJobKeys(groupEquals(group))) { 
     System.out.println("Found job identified by: " + jobKey); 
    } 
} 

Jeśli widzisz to samo zadanie dodany dwukrotnie, sprawdź org.quartz.spi.JobFactory i metoda org.quartz.Scheduler.setJobFactory do kontrolowania zadań zadań.

Upewnij się również, że masz tylko jeden wpis dotyczący tego procesu w tabeli "Raport i proces" w Openbravo.

Użyłem DalBaseProcess w Openbravo 3.0 i nie mogę potwierdzić tego zachowania, które opisujesz. Mając to na uwadze, prawdopodobnie warto byłoby sprawdzić zgłoszone błędy dla Openbravov2.50MP24 i Quartz lub opublikować wątek na forach Openbravo Forge z Twoim problemem.

Powiązane problemy