Jython 2.5.3 и time.sleep

Разработвам малка собствена алтернатива на Tripwire, така че кодирах малък скрипт за хеширане на файлове в JBoss EAP сървър и съхранявам пътя и хеша в MySQL база данни.

Всеки ден скриптът сравнява хешовете във файловата система с тези, записани в DB, ​​така че всяка промяна се регистрира и накрая се докладва с помощта на JasperServer.

Скриптът се изпълнява през нощта с помощта на cron, за да се избегнат голям брой скриптове, питащи DB в същото време, когато използва time.sleep(RANDOM_NUMBER_OF_SECONDS), преди да направи забавните неща, но понякога изглежда, че time.sleep спи завинаги и скриптът завършва без някаква грешка, проверявам пощата, която cron изпраща и не се регистрира грешка. Всяка помощ ще бъде оценена. Използвам jython-standalone-2.5.3, JDK на IBM и RHEL 5.6, работещи във VMWare.

Току-що намерих http://bugs.jython.org/issue1974 и изглежда, че коментарът на кода сочи, че OS сигналите могат да причинят това поведение, но не съм сигурен дали това е моят случай.

Ако искате да видите плащането на кода на http://code.google.com/p/pysnapshot/

Луис Гарсия Бустос.


vmware jython rhel5 jdk1.6
person user1877237    schedule 04.12.2012    source източник

Отговори (1)


arrow_upward
0
arrow_downward

Не знам защо смятате, че time.sleep() може да направи по-малък брой скриптове, заявявайки DB.

IMO не е по-добре да използвате cron за периодично извикване на тази програма. След стартиране трябва да провери дали в директорията /tmp/ има "семафорен" файл, например /tmp/snapshot_working.txt. Ако няма семафорен файл, създайте го и напишете в него нещо като: "моментната снимка стартира: 2012-12-05 22:00:00". След като програмата ви завърши проверката, тя трябва да премахне този файл. Ако при стартиране програмата намери семафорен файл, тогава може просто да спре или да провери дали датата и часът, записани в този файл, изглеждат "стари". Ако е "стар", премахнете го и започнете нормално да записвате в журнала, че е намерен "стар" файл (администраторът може да намери такива дълги работещи моментни снимки и да ги прекрати).

Единствената причина да направите time.sleep() във вашия случай е, ако искате да използвате такъв скрипт в нормално работно време, без да извършвате атака за отказ на услуга към вашата база данни. Пример: след като направите 100 DB заявки, можете да спите малко и да дадете време на DB да обслужва други потребителски заявки. Но мисля, че колкото по-скоро приключи програмата, толкова по-добре.

person Michał Niklas    schedule 05.12.2012
comment
здрасти прав си, използвам time.sleep, защото MySQL не може да се справи с натоварването, работейки в 100+ сървъра, тъй като стартирам всички скриптове едновременно (в пакетния прозорец) и използвам транзакции - защото частично моментната снимка е безполезна за целите на проверката на целостта - MySQL просто не може да се справи с нея и транзакциите започват да се прекъсват, така че използвам вид експоненциално забавяне за възстановяване. Основният проблем е, че когато поставя скрипта да изчака (използвайки time.sleep), преди да опитам отново операция, той изглежда никога не се събужда. Изобщо не използвам резба. - person user1877237; 05.12.2012
comment
Колко скрипта стартирате? Използват ли същия MySQL сървър? Проверявате ли една файлова система? Защо не стартирате един скрипт, за да проверявате една директория след друга (дълъг команден ред или конфигурационен файл)? - person Michał Niklas; 06.12.2012