Только для того же воркера. Остальные будут работать как обычно.
Я про ситуацию, когда проблемных заданий больше чем воркеров.
Не может получиться так, что воркер после перезапуска снова возмет проблемную задачу, которая вернулась в начало очереди?
Не понял, что произойдет если воркер взял задачу в обработку и упал на полпути?
Что будет с «плохой» задачей? Будет ли она отмечена как обработанная?
Если нет, то вернется ли она в очередь?
Если вернется, то как скоро и с каким приоритетом? На прежнее место или в конец? Не тормознет ли «плохая» задача всю очередь?
Как работают приоритеты? Сначала будут выполнены все задачи с высоким приоритетом, затем с низким, или есть какое-то чередование (2 с высоким, 1 с низким)?
Есть ли возможность перезапустить задания за определенный интервал времени?
Сначала я хотел чисто поржать над разработчиками замечательного онлайн-тестирования. Но потом в мою голову закралась шальная мысль — а с чего, собственно, я решил, что проверка обычного «бумажного» ЕГЭ написана не теми же криворукими программерами?
При проверке ЕГЭ составляется веер ответов по каждому пункту, из всех уникальных ответов вручную выбираются правильные и делается это после проведения экзамена, а не до. Если в ответе подразумевается Петр Первый, то правильными будут и «Петр» и «Петр 1» и «Петр I» с пробелами и без (это реальный пример).
В вашем случае имеет место некорректный тест. Идеальным вариантом было бы взять задание прошлого года вместе с ответами, но не знаю насколько такая информация доступна для создателей онлайн-теста.
Я всецело поддерживаю FB, но пошаговая отладка процедур в IBE — это миф. Сам FB такую фичу не поддерживает, а то что есть в IBE — это эмуляция, и она не всегда работает так как надо. Эта тема с завидной регулярностью поднимается на sql.ru
Никто не утверждает, что это решение подходит для всех.
Понятно, что для блога это не подойдет. Другое дело, когда необходимо предоставить доступ к корпоративной СУБД, целостность данных в которой важнее затрат на поддержание такой архитектуры.
Однако сия замечательная функция не работает применительно к MySQL. Потому...
надо было оставить MySQL. Не для этого она.
PS
данный подход имеет место для систем со сложной БД и логикой, особенно когда с БД работает более одного приложения. в данном случае, наличие единого согласованного api на уровне субд это плюс.
Может быть потому, что свое решение гугл позиционирует как встраиваемое. В таком случае вполне логично сравнить его SQLite.
В среднем по больнице 13 запросов в день на приложение.
Получается, что большинство приложений не используются.
К чему такая статистика?
Я про ситуацию, когда проблемных заданий больше чем воркеров.
Не может получиться так, что воркер после перезапуска снова возмет проблемную задачу, которая вернулась в начало очереди?
Вот это и смущает. Получается, что несколько проблемных задач в начале очереди застопорят последующие задачи.
Что будет с «плохой» задачей? Будет ли она отмечена как обработанная?
Если нет, то вернется ли она в очередь?
Если вернется, то как скоро и с каким приоритетом? На прежнее место или в конец? Не тормознет ли «плохая» задача всю очередь?
Как работают приоритеты? Сначала будут выполнены все задачи с высоким приоритетом, затем с низким, или есть какое-то чередование (2 с высоким, 1 с низким)?
Есть ли возможность перезапустить задания за определенный интервал времени?
Однозначно не таким как как хелпдеск от IBM.
Извините, наболело…
При этом я и так сижу на последнем FF, хочется более умной рекламы.
Брюнетка звала рыженькую подружку и они вместе шли в душ…
Skype.exe?
При проверке ЕГЭ составляется веер ответов по каждому пункту, из всех уникальных ответов вручную выбираются правильные и делается это после проведения экзамена, а не до. Если в ответе подразумевается Петр Первый, то правильными будут и «Петр» и «Петр 1» и «Петр I» с пробелами и без (это реальный пример).
В вашем случае имеет место некорректный тест. Идеальным вариантом было бы взять задание прошлого года вместе с ответами, но не знаю насколько такая информация доступна для создателей онлайн-теста.
в FF4 есть
Понятно, что для блога это не подойдет. Другое дело, когда необходимо предоставить доступ к корпоративной СУБД, целостность данных в которой важнее затрат на поддержание такой архитектуры.
надо было оставить MySQL. Не для этого она.
PS
данный подход имеет место для систем со сложной БД и логикой, особенно когда с БД работает более одного приложения. в данном случае, наличие единого согласованного api на уровне субд это плюс.