- Can I use supertag/gearman-bundle in a Laravel application?
- No. This is a Symfony2-era bundle that depends on AppKernel, bundle registration, and Symfony dependency-injection conventions, so it does not map cleanly to Laravel. Laravel applications should use the framework's native queue abstraction with Redis, SQS, database, or another supported driver. Horizon or an equivalent tool is the idiomatic monitoring path for Laravel queues.
- Which Symfony versions does supertag/gearman-bundle support?
- The package is described as a Symfony2 bundle, so it is intended for the pre-Symfony 4 framework lineage. There is no evidence of a supported version matrix or CI coverage, so compatibility with later Symfony releases should not be assumed. For modern Symfony, Symfony Messenger with a transport and failure transport is the appropriate replacement.
- What are the installation requirements for supertag/gearman-bundle?
- You need a Symfony2 application that can accept third-party bundles, a running gearmand job server, and the PECL gearman PHP extension. Installation also involves Composer, bundle registration, and service configuration for workers and queue monitoring. Because there is no published compatibility matrix, verify each prerequisite in a non-production spike before planning adoption.
- Does supertag/gearman-bundle require gearmand and the PECL gearman extension?
- Yes. The bundle wraps Gearman, which presumes a long-running gearmand job server and the PECL gearman PHP extension. Both are hard external prerequisites on top of the Symfony2 application itself. If either the server or the extension is unavailable for your target runtime, integration is a non-starter.
- Is supertag/gearman-bundle still maintained?
- There is no evidence of active maintenance, CI, or test coverage in the assessment. Zero stars and zero dependents mean there is no peer review, downstream bug reporting, or community security coverage. The bus factor is effectively one, so reachability of the maintainer should be confirmed before any serious evaluation.
- Is supertag/gearman-bundle safe for production job processing?
- The technical risk is very high because an unmaintained dependency would sit on the critical path for every async workload. There are no known security advisories, but the absence of a community also means no one is likely to report or patch issues. Treat it as evaluate, do not adopt unless a compelling legacy constraint justifies the risk.
- Does supertag/gearman-bundle support durable retries or at-least-once delivery?
- The bundle exposes Gearman-style fire-and-forget job semantics and does not provide built-in persistence. That makes it a poor fit for workloads that require durable retries or at-least-once delivery guarantees. If durability is the real requirement, use a queue system designed around persisted messages and explicit failure handling.
- How should I test supertag/gearman-bundle compatibility?
- Run a spike in a non-production environment using your target PHP runtime, gearmand, and Symfony2 application. Validate bundle registration, worker registration by function name, job dispatch, and the monitoring view against a small inventory of real worker scripts. Do not rely on the README alone, because there is no evidence of CI or a verified supported version matrix.
- What are the best alternatives to supertag/gearman-bundle for Laravel and modern Symfony?
- For Laravel, use the native queue system with Redis, SQS, or database drivers and Horizon or equivalent monitoring. For modern Symfony, use Symfony Messenger with a transport and its failure transport. This bundle is only defensible in a legacy Symfony2 application that already operates gearmand and cannot rewrite its async layer.
- What is the migration or exit cost if we adopt supertag/gearman-bundle?
- Exit cost is significant unless you isolate the bundle behind a thin internal interface. Inventory existing Gearman function registrations and worker scripts, then make application code depend on your abstraction rather than directly on the bundle. That interface is the real deliverable because it keeps a future replacement of the bundle or transport from becoming an application-wide rewrite.