Transports are the foundations behind the storage of tasks: once tasks are defined in the configuration or scheduled via the Scheduler, every task is stored via transports.
Think of transports like the transports used by the following components in Symfony:
This bundle defines a set of transports, each transport has its own configuration and can be overridden if required.
Once created, the transport is injected into the Scheduler,
you will probably never need to interact with it without using the Scheduler, otherwise,
the transport is injected using the TransportInterface
and the scheduler.transport identifier.
<?php
declare(strict_types=1);
use SchedulerBundle\Transport\TransportInterface;
use Symfony\Component\HttpFoundation\Request;
final class FooController
{
public function __invoke(Request $request, TransportInterface $transport)
{
// ...
}
}Note: Using the transport without the scheduler can lead to edge issues as the scheduler is synchronized with it.
Every transport has its own configuration keys (thanks to query parameters), here's the default keys:
execution_mode: Define the schedule policy used by the transports (more info on Policies).path: Define the path used by the FilesystemTransport.
The InMemoryTransport stores every task in memory,
this transport is perfect for test environnement or/and for POC applications.
scheduler_bundle:
transport:
dsn: 'memory://first_in_first_out'Configuration: This transport requires that you provide an execution_mode as the first parameter,
this value is used to sort every new task and improve performances/resources consumption.
The FilesystemTransport stores every task in files,
the default path is %kernel.project_dir%/var/tasks.
scheduler_bundle:
transport:
dsn: 'filesystem://first_in_first_out' # OR 'fs://first_in_first_out' OR 'file://first_in_first_out'Configuration:
-
This transport requires that you provide an
execution_modeas the first parameter, this value is used to sort every new task and improve performances/resources consumption. -
The second and optional key is the
pathwhere every task is stored (usingjsonformat):
scheduler_bundle:
transport:
dsn: 'filesystem://first_in_first_out?path=/srv/app'- The third and optional key is the
filename_maskwhich define the "mask" of every task file (default to%s/_symfony_scheduler_/%s.json):
scheduler_bundle:
transport:
dsn: 'filesystem://first_in_first_out?filename_mask=%s/_foo/%s.json'Important: This configuration key must use the json file extension,
the mask is used in combination with the path configuration key to store every task.
Note: Container parameters cannot be passed here as the container is not involved in the transport configuration.
Note: Keep in mind that this directory could be versioned if required
Introduced in 0.4
The CacheTransport stores every task in a PSR compliant
CacheItemPoolInterface, every cache adapter that implement this interface can be used.
By default, this bundle use the ones defined in the cache configuration key of the framework:
framework:
cache:
app: cache.adapter.filesystemscheduler_bundle:
transport:
dsn: 'cache://app'Configuration: This transport requires that you provide the name of the pool to use, the execution_mode option is allowed.
The FailOverTransport allows to use multiple transports and "prevent" errors when trying to schedule a task, this approach is also known as "High-Availability", it is particularly useful if you use a transport that can fail during an operation (like network-related, etc).
scheduler_bundle:
transport:
dsn: 'failover://(memory://first_in_first_out || memory://last_in_first_out)' # Or 'fo://(memory://first_in_first_out || memory://last_in_first_out)'configuration: This transport requires at least 2 transports to be used (each one can be configured as usual).
The LongTail allows to use multiple transports. It's specifically designed to maximize the transport usage by always trying to use the transport with the lowest amount of tasks. This approach can help when you're scheduling tasks in a high-stress environment.
scheduler_bundle:
transport:
dsn: 'longtail://(memory://first_in_first_out <> memory://last_in_first_out)' # Or 'lt://(memory://first_in_first_out <> memory://last_in_first_out)'configuration: This transport requires at least 2 transports to be used (each one can be configured as usual).
The RoundRobin allows using multiple transports, the main advantages of this transport is to distribute the work load around multiple transports, think of it as a "load-balancer" transport.
scheduler_bundle:
transport:
dsn: 'roundrobin://(memory://first_in_first_out && memory://last_in_first_out)' # Or 'rr://(memory://first_in_first_out && memory://last_in_first_out)'- This transport requires at least 2 transports to be used (each one can be configured as usual).
- A
quantumcan be defined to determine the maximum duration (expressed in seconds) within a transport MUST perform the action, the default value is2.
Note: By default, the execution duration limit is based around the formula: count(transports) * quantum.
The LazyTransport allows to perform actions using an asynchronous approach.
scheduler_bundle:
transport:
dsn: 'lazy://(memory://batch)'Introduced in 0.9
The FiberTransport allows performing actions using native fibers.
scheduler_bundle:
transport:
dsn: 'fiber://(memory://batch)'The RedisTransport allows to use Redis as tasks storage, this transport is useful if you need to share tasks between multiple projects/instances.
Requirements: The Redis transport requires at least redis >= 4.3.
scheduler_bundle:
transport:
dsn: 'redis://user:password@host:port'configuration: This transport requires multiple options:
- The
userof the Redis instance - The related
password - The
hostof the Redis instance - The optional
portof the Redis instance
This transport can be configured using multiple options:
execution_mode: Relates to default configuration keys.list: Define the name of the list that store tasks.
scheduler_bundle:
transport:
dsn: 'redis://user:password@127.0.0.1:6543?execution_mode=first_in_first_out&list=foo'The DoctrineTransport allows to use Doctrine connections as tasks storage. This transport is useful if you need to share tasks between multiple projects/instances.
scheduler_bundle:
transport:
dsn: 'doctrine://default?execution_mode=first_in_first_out' # Or 'dbal://default?execution_mode=first_in_first_out'Configuration: This transports requires the following configuration keys:
- The
connectionname as the "host" - The optional
table_namewhere the tasks must be stored (default to_symfony_scheduler_tasks) - The optional
auto_setupto define if the connection should configure the table if it does not exist
This transport can configure multiple options:
execution_mode: Relates to default configuration keys.
scheduler_bundle:
transport:
dsn: 'doctrine://default?execution_mode=first_in_first_out&table_name=foo&auto_setup=false'The Doctrine bride integrate deeply with the Doctrine bundle,
the first integration is done via the connection which is retrieved via the doctrine service,
the second integration is done via DoctrineMigrationsBundle,
thanks to this one and when using bin/console doctrine:migrations:diff, the schema related to the task list can be generated.
Note: An important thing to keep in mind is that if you don't use the DoctrineMigrationsBundle bundle
and the auto_setup option is set to true, the schema is generated when scheduling the tasks.
If desired, you can create your own transport thanks to TransportInterface, it requires that you create your own transport factory via TransportFactoryInterface.
Once created, both classes will be autoconfigured and autowired into the related classes.