 |
VOOZH | about |
|
VOOZH | about |
This document covers the transport layer and HTTP client implementation used by the Hypervel Sentry integration to communicate with the Sentry.io platform. Specifically, it documents the custom HttpPoolTransport for asynchronous event submission using connection pooling, the Pool class for managing HTTP connections, and the HttpClientFactory for creating HTTP clients with SDK identification.
For information about how the Hub uses these components to capture and send events, see Hub and Client Management. For configuration of transport and pooling options, see Configuration.
The Hypervel Sentry integration implements a custom transport layer to enable efficient, asynchronous communication with Sentry.io. Unlike synchronous transports that block request processing, the HttpPoolTransport leverages Hypervel's connection pooling capabilities to send events without blocking coroutines. This design is critical for high-performance async applications where blocking I/O would significantly degrade throughput.
The transport layer consists of three main components:
| Component | Purpose | Key Benefit |
|---|---|---|
HttpPoolTransport | Sentry transport implementation | Async event submission without blocking |
Pool | Connection pool manager | Reuses HTTP connections efficiently |
HttpClientFactory | HTTP client factory | Creates clients with SDK version headers |
Sources: src/SentryServiceProvider.php1-143
The following diagram illustrates how the transport layer components relate to each other and to the Sentry SDK:
Sources: src/SentryServiceProvider.php65-75 src/HttpClient/HttpClientFactory.php1-19
The HttpPoolTransport is a custom implementation of Sentry's TransportInterface that uses connection pooling for asynchronous event submission. Instead of creating a new HTTP connection for each event, it delegates to a managed connection pool, allowing multiple events to be sent concurrently without resource exhaustion.
The transport is registered during the service provider's registration phase by extending the ClientBuilder class. This approach allows the custom transport to replace the SDK's default transport seamlessly:
The transport is configured at src/SentryServiceProvider.php65-75:
A new Pool instance is created with:
ClientBuilderconfig.pools.sentryThe HttpPoolTransport wraps the Pool instance
The transport is set on the ClientBuilder using setTransport()
Sources: src/SentryServiceProvider.php65-75
When the Sentry client needs to send an event, the flow proceeds as follows:
The key advantage is that the Pool::send() method is non-blocking, allowing the coroutine to continue processing while the event is transmitted in the background.
Sources: src/SentryServiceProvider.php65-75
The Pool class manages a pool of reusable HTTP connections for communicating with Sentry.io. It is instantiated with three dependencies:
| Parameter | Type | Purpose |
|---|---|---|
$options | Options | Sentry SDK options (DSN, environment, etc.) |
$app | Application | Container for resolving dependencies |
$poolConfig | array | Pool-specific configuration (size, timeouts, etc.) |
Pool configuration is read from the pools.sentry configuration key. This allows operators to tune connection pool behavior based on application needs:
Configuration Path: config.pools.sentry
Typical configuration might include:
min_connections - Minimum connections to maintainmax_connections - Maximum connections to createwait_timeout - How long to wait for an available connectionmax_idle_time - When to close idle connectionsSources: src/SentryServiceProvider.php70
Sources: src/SentryServiceProvider.php67-72
The HttpClientFactory creates instances of HttpClient with proper SDK identification headers. This ensures that Sentry.io can track which SDK and version is sending events, enabling version-specific features and diagnostics.
The factory is bound to the HttpClientInterface in the service container and resolves the HttpClient class:
Implementation: src/HttpClient/HttpClientFactory.php10-19
The factory's __invoke() method receives the application container and creates an HttpClient with:
Version::getSdkIdentifier() (e.g., "sentry.php.hypervel")Version::getSdkVersion() (e.g., parsed from composer.json)The HttpClient includes these values in HTTP headers when communicating with Sentry.io:
| Header | Value Source | Purpose |
|---|---|---|
User-Agent | SDK identifier + version | Identifies the SDK to Sentry.io |
X-Sentry-SDK | SDK identifier + version | Parsed by Sentry for analytics |
This enables Sentry to:
Sources: src/HttpClient/HttpClientFactory.php1-19
The transport and HTTP client components are registered during the SentryServiceProvider::register() phase, before any features are booted. This ensures that when features need to capture events, the transport layer is fully configured.
Key Points:
ClientBuilder is extended first, injecting the custom transportClientInterface is bound to resolve from the configured builderThis ordering ensures that features like CacheFeature, QueueFeature, and RedisFeature can immediately start capturing spans and events without transport initialization failures.
Sources: src/SentryServiceProvider.php63-87
The following diagram shows how configuration flows from various sources into the transport layer:
Configuration Keys:
| Key Path | Component | Purpose |
|---|---|---|
sentry.dsn | Options | Sentry project DSN |
sentry.environment | Options | Environment name (production, staging, etc.) |
sentry.traces_sample_rate | Options | Sampling rate for transactions |
pools.sentry | Pool | Connection pool configuration |
Sources: src/SentryServiceProvider.php65-75 src/HttpClient/HttpClientFactory.php10-19
The transport layer components use Laravel/Hypervel's dependency injection container for resolution. The following table shows the bindings:
| Abstract | Concrete | Resolution Strategy |
|---|---|---|
ClientBuilder::class | ClientBuilderFactory::class | Factory pattern via bind() |
ClientInterface::class | Resolved via ClientBuilder::getClient() | Closure binding at src/SentryServiceProvider.php77-81 |
HttpClientInterface::class | HttpClientFactory::class | Factory pattern via bind() |
When any component requests a ClientBuilder, the container invokes ClientBuilderFactory, which creates a builder pre-configured with:
HttpPoolTransport (set via extension at src/SentryServiceProvider.php65-75)Sources: src/SentryServiceProvider.php63-87 src/HttpClient/HttpClientFactory.php1-19
The custom transport implementation provides several advantages over the SDK's default HTTP transport:
| Benefit | Description | Implementation |
|---|---|---|
| Non-blocking I/O | Events are sent without blocking the current coroutine | Connection pool operates asynchronously |
| Connection Reuse | HTTP connections are reused across multiple events | Pool manages connection lifecycle |
| Resource Efficiency | Limited number of connections prevents resource exhaustion | Pool enforces max connection limits |
| Backpressure Handling | When pool is exhausted, sends can wait or fail gracefully | Pool configuration controls wait behavior |
| Performance | Reduced latency for event submission | Persistent connections eliminate handshake overhead |
This design is essential for Hypervel applications that use Swoole or other async runtimes, where blocking I/O would create significant performance bottlenecks.
Sources: src/SentryServiceProvider.php65-75
The transport and HTTP client layer of the Hypervel Sentry integration consists of:
pools.sentry configurationThese components are registered during SentryServiceProvider::register() and work together to provide efficient, non-blocking communication with Sentry.io. The connection pooling strategy ensures that high-throughput async applications can send telemetry data without performance degradation.
Sources: src/SentryServiceProvider.php1-143 src/HttpClient/HttpClientFactory.php1-19
Refresh this wiki