Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Job fails to get container if the queue is created from different host and has different kernel root dir. #96

Open
cocomode18 opened this issue Apr 10, 2014 · 3 comments

Comments

@cocomode18
Copy link
Contributor

I have separate hosts, one that creates the queue, and other that processes the worker and job.
When each server has different project root directories, it fails to get the container in ContainerAwareJob class.

I've found out why, but can't get this to work unless I hard code the root_dir in my project that create's the worker (which I don't like to do). Is there any suggestions to fix this??

related codes below

  • the Resque class calles the following method and adds kernelOptions (of the server creating queue) to $args before sending it to redis (which is listening on different host).
// ContainerAwareJob.php
public function setKernelOptions(array $kernelOptions)
{
    $this->args = \array_merge($this->args, $kernelOptions);
}
  • the ContainerAwareJob class fetches the kernelOption info from redis when running the job and fails to create the container, since app root is not the same as the queueing server.
// ContainerAwareJob.php
protected function createKernel()
{
    /**/
     $finder->name('*Kernel.php')->depth(0)->in($this->args['kernel.root_dir']);
    /**/
}
@cocomode18
Copy link
Contributor Author

update

temporary, I solved it by adding a new config param that defines the worker server app_root_dir.

  • add following
# app/config/config.yml
bcc_resque:
    worker:
        root_dir: 'path/to/root'
// DependencyInjection/Configuration.php
public function getConfigTreeBuilder()
{
    /**/
    $rootNode
        ->addDefailtsIfNotSet()
        ->children()
                ->arrayNode('worker')
                    ->info('Worker Server configuration')
                    ->addDefaultsIfNotSet()
                    ->children()
                        ->scalarNode('root_dir')
                            ->defaultValue('%kernel.root_dir%')
                            ->cannotBeEmpty()
                            ->info('The root dir of worker registered app')
                        ->end()
                    ->end()
                ->end()
    /**/
}
// DependencyInjection/BCCResqueExtension.php
public function load(array $configs, ContainerBuilder $container {
  /**/
  if (!empty($config['worker']['root_dir'])) {
           $container->setParameter('bcc_resque.worker.root_dir', $config['worker']['root_dir']);
  }
  /**/
  • modify following
# Resources/config/services.xml  line20
<!--<argument key="kernel.root_dir">%kernel.root_dir%</argument>-->
<argument key="kernel.root_dir">%bcc_resque.worker.root_dir%</argument>

It would be better if I can just get the root_dir of the worker server without setting any configurations.

@michelsalib
Copy link
Owner

Hi @cocomode18, can you create a PR?

@calumbrodie
Copy link

I've also ran into this issue, but on a single machine. Because the kernel.root_dir is stored in Redis at the time the job is created, and this is stored as an absolute path, it contains the current release directory of my application.

As such, if I make a release, which changes the current working directory, all jobs on the queue with the previous kernel.root_dir value are executed against the old (out of date) version of the application.

Also - if I make multiple releases in quick succession, it's possible for the kernel to not even exist when the job is due to run.

The above allows my to define the root directory as a symlink instead circumventing the problem. Any chance this can be merged?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants