International PHP Conference 2015

GearmanClient::addTaskBackground

(PECL gearman >= 0.5.0)

GearmanClient::addTaskBackgroundEjecuta una tarea en segundo plano para ser ejecutada en paralelo

Descripción

public GearmanTask GearmanClient::addTaskBackground ( string $function_name , string $workload [, mixed &$context [, string $unique ]] )

Añade una tarea en segundo plano para ser ejecutada en paralelo junto con otras tareas. Este método debe llamarse para todas las tareas que deben ejecutarse en paralelo y entonces llamar a GearmanClient::runTasks() para realizar el trabajo.

Parámetros

function_name

Función registrada que ejecutará el worker

workload

Datos serializados a ser procesados

context

Aplicación context a asociar con la tarea

unique

ID único para identificar una tarea en particular

Valores devueltos

Un objeto GearmanTask o FALSE si la tarea no pudo ser añadida.

Ejemplos

Ejemplo #1 Dos tareas, una en segundo plano y la otra no

Este ejemplo ilustra la diferencia entre ejecutar una tarea en segundo plano y una tarea normal. El cliente añade dos tareas para que ejecuten la misma función, pero una se añade con addTaskBackground(). Se establece una llamada de retorno de modo que se puede hacer seguimiento del progreso del trabajo. Un trajabador muy simple con un retardo artificial informa sobre el progreso del trabajo y el cliente obtiene esta información a través de la llamada de retorno. En este ejemplo se ejecutan dos trabajadores. Notar que la tarea en segundo plano no se muestra en la información de salida del cliente.

<?php

# El script del cliente

# Creamos el cliente gearman
$gmc= new GearmanClient();

# Añade el servidor de trabajos por defecto
$gmc->addServer();

# Establece un par de llamadas de retorno de modo que pueda seguirse el progreso
$gmc->setCompleteCallback("reverse_complete");
$gmc->setStatusCallback("reverse_status");

# Añade una tarea para la función "reverse"
$task$gmc->addTask("reverse""Hello World!"null"1");

# Añade otra tarea, pero esta se ejecuta en segundo plano
$task$gmc->addTaskBackground("reverse""!dlroW olleH"null"2");

if (! 
$gmc->runTasks())
{
    echo 
"ERROR " $gmc->error() . "\n";
    exit;
}

echo 
"DONE\n";

function 
reverse_status($task)
{
    echo 
"STATUS: " $task->unique() . ", " $task->jobHandle() . " - " $task->taskNumerator() . 
         
"/" $task->taskDenominator() . "\n";
}

function 
reverse_complete($task)
{
    echo 
"COMPLETE: " $task->unique() . ", " $task->data() . "\n";
}

?>
<?php

# El script del trabajador

echo "Starting\n";

# Creamos el objeto trabajador
$gmworker= new GearmanWorker();

# Añade el servidor por defecto (localhost)
$gmworker->addServer();

# Registra la función "reverse" en el servidor
$gmworker->addFunction("reverse""reverse_fn");

print 
"Waiting for job...\n";
while(
$gmworker->work())
{
  if (
$gmworker->returnCode() != GEARMAN_SUCCESS)
  {
    echo 
"return_code: " $gmworker->returnCode() . "\n";
    break;
  }
}

function 
reverse_fn($job)
{
  echo 
"Received job: " $job->handle() . "\n";

  
$workload $job->workload();
  
$workload_size $job->workloadSize();

  echo 
"Workload: $workload ($workload_size)\n";

  
# Este bucle de estado no es neceasario, únicamente muestra cómo funciona
  
for ($x0$x $workload_size$x++)
  {
    echo 
"Sending status: " $x "/$workload_size complete\n";
    
$job->sendStatus($x+1$workload_size);
    
$job->sendData(substr($workload$x1));
    
sleep(1);
  }

  
$resultstrrev($workload);
  echo 
"Result: $result\n";

  
# Retorna lo que se quiere enviar al cliente
  
return $result;
}

?>

Salida del trabajador para dos trabajadores en funcionamiento:

Received job: H:foo.local:65
Workload: !dlroW olleH (12)
1/12 complete
Received job: H:foo.local:66
Workload: Hello World! (12)
Sending status: 1/12 complete
Sending status: 2/12 complete
Sending status: 2/12 complete
Sending status: 3/12 complete
Sending status: 3/12 complete
Sending status: 4/12 complete
Sending status: 4/12 complete
Sending status: 5/12 complete
Sending status: 5/12 complete
Sending status: 6/12 complete
Sending status: 6/12 complete
Sending status: 7/12 complete
Sending status: 7/12 complete
Sending status: 8/12 complete
Sending status: 8/12 complete
Sending status: 9/12 complete
Sending status: 9/12 complete
Sending status: 10/12 complete
Sending status: 10/12 complete
Sending status: 11/12 complete
Sending status: 11/12 complete
Sending status: 12/12 complete
Sending status: 12/12 complete
Result: !dlroW olleH
Result: Hello World!

Salida del cliente:

STATUS: 1, H:foo.local:66 - 1/12
STATUS: 1, H:foo.local:66 - 2/12
STATUS: 1, H:foo.local:66 - 3/12
STATUS: 1, H:foo.local:66 - 4/12
STATUS: 1, H:foo.local:66 - 5/12
STATUS: 1, H:foo.local:66 - 6/12
STATUS: 1, H:foo.local:66 - 7/12
STATUS: 1, H:foo.local:66 - 8/12
STATUS: 1, H:foo.local:66 - 9/12
STATUS: 1, H:foo.local:66 - 10/12
STATUS: 1, H:foo.local:66 - 11/12
STATUS: 1, H:foo.local:66 - 12/12
COMPLETE: 1, !dlroW olleH
DONE

Ver también

add a note add a note

User Contributed Notes 1 note

up
0
Anonymous
3 days ago
It is unlikely this example works quite as advertised.

The foreground job will block, however the background job should not.. (and if it does that's not documented Gearman behaviour far as I know and would not make sense for a Background job).

So, if the foreground job completes, then we would expect runTasks() to return at that moment, regardless of the status of the background job(s). With nothing else to do, the php script (the client) in this example would exit at that point.

To fully-utilize background jobs, it's reasonable to assume that we still wish to know their status. To do that, you need a polling loop that "checks up on them" and waits until their completion.

That eliminates the point of background jobs of course - because the client would still be Blocking (in a polling loop) more or less occupied, and unable to exit/finish.

So, in practice, background jobs mean you are decoupled from the client upon execution (because the main point is to free up the client, otherwise just use foreground execution), which means the client is likely going to exit, meaning the jobs themselves should be reporting their status and final result independently, not leaving it up to the client.

It's a significantly different setup compared to foreground jobs. In fact this example is kind of silly to even mix the two.

Nobody will ever see this post, because apparently nobody in the world has ever commented on the php gearman client, but it's a good post never the less.
To Top