Эластичное масштабирование Gridgain - не могу заставить работу воровства вести себя так, как я хочу

Я надеюсь, что кто-то делал это раньше, или если кто-то может посоветовать, поддерживает ли Gridgain эту функциональность.

Мой вариант использования:

  1. Запустите узел Gridgain, используя examples/config/example-compute.xml, измененный для поддержки кражи работы (см. ниже).
  2. Отправьте 300 задач в кластер. Они начинают выполняться на первом узле, но поскольку для их выполнения требуется время, возникает длинная очередь невыполненных задач.
  3. Запустите новый узел с той же конфигурацией и посмотрите, как он присоединится к кластеру.
  4. Разве узел 2 не должен украсть часть работы у первого узла? К сожалению, это не так, и нам нужно дождаться завершения всех задач на узле 1, в то время как узел 2 ничего не делает.

Я думаю, что GridJobStealingCollisionSpi что-то делает, потому что когда я включаю ведение журнала отладки, я вижу в журнале следующее сообщение: Thief node does not belong to task topology [...]. и просматривая исходный код, я думаю, что происходит то, что GridJobStealingCollisionSpi проверяет, находится ли узел кражи в топологии, для которой было отправлено задание.

Кто-нибудь видел, как мой вариант использования работает так, как я ожидал?

Я изменил example-compute.xml (полный файл можно найти на pastebin.com/gGsfEebG) для поддержки кражи работы, добавив следующую конфигурацию:

<property name="collisionSpi">
    <bean class="org.gridgain.grid.spi.collision.jobstealing.GridJobStealingCollisionSpi">
        <property name="activeJobsThreshold" value="50" />
        <property name="waitJobsThreshold" value="10" />
        <property name="messageExpireTime" value="1000" />
        <property name="maximumStealingAttempts" value="100" />
        <property name="stealingEnabled" value="true" />
    </bean>
</property>
<property name="failoverSpi">
    <bean class="org.gridgain.grid.spi.failover.jobstealing.GridJobStealingFailoverSpi">
        <property name="maximumFailoverAttempts" value="5" />
    </bean>
</property>
<property name="metricsUpdateFrequency" value="1000"/>

Мой класс Java можно найти в pastebin здесь: http://pastebin.com/AS8iKqjj, а здесь подробные инструкции по запустить его:

  1. запустить класс ComputeSleepExample, который запускает узел и отправляет в кластер 300 заданий, которые будут спать в течение 5 секунд.

    java -DGRIDGAIN_DEBUG_ENABLED=true -DGRIDGAIN_QUIET=false -cp examples/config:examples/target/classes:examples/target/libs/*:target/gridgain-‌​6.1.9.jar:modules/spring/target/gridgain-spring-6.1.9.jar org.gridgain.examples.compute.ComputeSleepExample 300 5000

  2. запустите новый узел, и вы увидите, что все задания выполняются на узле 1

    bin/ggstart.sh examples/config/example-compute.xml


person Jerry Shea    schedule 07.08.2014    source источник
comment
Это следует поддерживать. Можете ли вы предоставить свой класс задачи и код, который его вызывает? Вы можете использовать pastebin.com, чтобы вставить свой код.   -  person Dmitriy    schedule 08.08.2014
comment
Привет, Дмитрий, я отредактировал свой пост, чтобы показать, где найти мой код и конфигурацию в pastebin.   -  person Jerry Shea    schedule 11.08.2014


Ответы (1)


Проблема в том, что в настоящее время задача определяет топологию своего узла на этапе сопоставления. Если вы добавляете новый узел после того, как задача уже завершила этап сопоставления, то новый узел не будет в топологии задачи. Вот почему он не участвует в краже работы.

Если вы начнете добавлять больше задач после запуска нового узла, то он должен немедленно начать участвовать в краже заданий.

Сказав это, можно сделать топологию задач динамической, поэтому кража заданий может украсть задания даже после этапа сопоставления. GridGain реализует это в будущем выпуске.

person Dmitriy    schedule 15.08.2014
comment
Ага - согласен. Не подскажете, когда это будет реализовано? - person Jerry Shea; 18.08.2014