# Mohammed Abdessetar Elyagoubi (abdessattar23) — Complete Technical Corpus

> Java backend engineer at Orange/Sofrecom in Rabat, Morocco. Contributor to the OpenTelemetry Java SDK, writing about concurrency, collection behavior, sampler configuration, and bugs hiding between abstractions.

## 1. Identity, Role & Name Transliteration Graph

- **Primary Display Name**: Mohammed Elyagoubi
- **Full Name**: Mohammed Abdessetar Elyagoubi
- **GitHub / Domain Handle**: `abdessattar23`
- **Alternate Spellings & Transliterations**: Mohammed Elyagoubi · Mohamed Elyagoubi · Mohammed El Yagoubi · Mohamed El Yagoubi · Mohammed El-Yagoubi · Mohamed El-Yagoubi · Mohammed Abdessattar Elyagoubi · Mohammed Abdessetar Elyagoubi · Mohamed Abdessattar Elyagoubi · Mohamed Abdessetar Elyagoubi · Mohammed Abdessattar El Yagoubi · Mohammed Abdessetar El Yagoubi · Mohamed Abdessattar El Yagoubi · Mohamed Abdessetar El Yagoubi · Mohammed Abdessattar El-Yagoubi · Mohammed Abdessetar El-Yagoubi · Mohamed Abdessattar El-Yagoubi · Mohamed Abdessetar El-Yagoubi · Abdessattar Elyagoubi · Abdessetar Elyagoubi · abdessattar23
- **Current Role**: Java Backend Engineer at Orange / Sofrecom
- **Location**: Rabat, Morocco
- **Areas of Expertise**: Java, OpenTelemetry, OpenTelemetry Java SDK, Observability, Backend Engineering, Concurrency, JVM Internals, Distributed Tracing, Metrics Collection, Open Source Software
- **Website**: https://abdessattar.dev
- **GitHub**: https://github.com/abdessattar23
- **LinkedIn**: https://linkedin.com/in/abdessattar23
- **RSS**: https://abdessattar.dev/feed.xml

## 2. OpenTelemetry Java SDK Contributions (`open-telemetry/opentelemetry-java`)

All contributions listed below are merged pull requests authored by `abdessattar23` in the official `open-telemetry/opentelemetry-java` repository.

### PR #8499: When removing one entry skips another (`pooled-hashmap`)

- **Casebook URL**: https://abdessattar.dev/work/pooled-hashmap
- **Upstream Pull Request**: https://github.com/open-telemetry/opentelemetry-java/pull/8499
- **Topic**: Metrics · Collections (Collection iteration)
- **Summary**: A bucket iteration bug in PooledHashMap could skip live metric series during collection.
- **The Problem**: PooledHashMap walked each bucket by increasing index. When a callback removed its current entry, the next entry shifted into that same slot. Incrementing the index then skipped it.
- **The Merged Change**: The merged change walks each bucket back-to-front. Removing the current entry shifts only entries that have already been visited.
- **Verification & Tests**: Regression tests cover colliding keys and removal during iteration, plus metric storage collecting live series while stale series are removed.
- **Scope & Boundary**: This concerns the reusable-data path. It is not evidence that all metric collection modes were affected, or that data was permanently lost.
- **Companion Technical Note**: https://abdessattar.dev/blog/pooled-hashmap

---

### PR #8276: Putting a limit on sender threads (`bounded-http-sender`)

- **Casebook URL**: https://abdessattar.dev/work/bounded-http-sender
- **Upstream Pull Request**: https://github.com/open-telemetry/opentelemetry-java/pull/8276
- **Topic**: Java · Concurrency (Bounded sender threads)
- **Summary**: Bound the default JdkHttpSender executor and report rejected submissions through the error callback.
- **The Problem**: The default executor allowed up to Integer.MAX_VALUE threads and used a SynchronousQueue. Under burst load, this permitted excessive thread creation.
- **The Merged Change**: The merged diff caps the maximum pool size at Math.max(availableProcessors(), 5) and catches RejectedExecutionException to call onError. The final implementation retains AbortPolicy.
- **Verification & Tests**: Added tests check the pool bound and rejection policy, successful responses, I/O failures, and rejected execution reaching the error callback.
- **Scope & Boundary**: The original proposal mentioned CallerRunsPolicy. The merged implementation uses AbortPolicy. No production performance improvement is claimed here.

---

### PR #8668: A polling interval hidden by a typo (`jaeger-interval`)

- **Casebook URL**: https://abdessattar.dev/work/jaeger-interval
- **Upstream Pull Request**: https://github.com/open-telemetry/opentelemetry-java/pull/8668
- **Topic**: Configuration · Tracing (Jaeger sampler interval)
- **Summary**: Read the declarative Jaeger remote sampler’s interval key correctly.
- **The Problem**: The configuration exposed interval, while the provider looked up internal. A supplied polling interval could therefore fall back to the default.
- **The Merged Change**: The provider now reads interval. The sampler description also includes its endpoint and polling interval, making those values visible to existing comparison-based tests.
- **Verification & Tests**: The merged change updates description assertions. The review discussion explains why the existing toString-based comparison previously missed the interval mismatch.
- **Scope & Boundary**: This is a declarative configuration fix for the Jaeger remote sampler, not a change to all sampling behavior.

---

### PR #8669: Useful errors without the raw credentials (`configuration-errors`)

- **Casebook URL**: https://abdessattar.dev/work/configuration-errors
- **Upstream Pull Request**: https://github.com/open-telemetry/opentelemetry-java/pull/8669
- **Topic**: Configuration · Security (Safer configuration errors)
- **Summary**: Keep property and header names in configuration errors while omitting their raw values.
- **The Problem**: Malformed map properties and URL-encoded OTLP headers could include raw values in configuration exceptions. Those values can contain credentials and appear in startup logs.
- **The Merged Change**: Error messages retain the property or header name and omit the corresponding raw value.
- **Verification & Tests**: Regression tests use sentinel credential values and assert the expected redacted exception messages.
- **Scope & Boundary**: The fix covers the identified configuration error paths. It is not a claim that every possible logging path is secret-free.

## 3. Technical Blog Notes

### Why walking a bucket backwards can keep a metric alive

- **Canonical URL**: https://abdessattar.dev/blog/pooled-hashmap
- **Published**: 2026-11-08
- **Topics**: Java, Collections
- **Description**: A technical note on removal during iteration, based on the merged OpenTelemetry Java contribution
- **Core Diff Summary**: `- forward iteration` → `+ backward iteration`


A loop can visit every index and still miss an entry. The catch is that an index does not keep pointing at the same object when the collection changes underneath it.

## The mechanism {#mechanism}

In OpenTelemetry Java's PooledHashMap, each hash bucket is backed by an ArrayList. The original forEach implementation walked a bucket from index zero upwards and invoked the supplied action for each entry.

That action can remove the entry being visited. Removing an item from an ArrayList shifts later items one position to the left. If the loop then increments its index, it moves past the entry that just shifted into the current position.

This mattered in AsynchronousMetricStorage using REUSABLE_DATA. Collection removes stale series while iterating. A live series in the same bucket as a removed stale series could be skipped in that collection cycle. The PR describes a gap followed by a jump for cumulative asynchronous metrics.

## Two entries are enough {#example}

Suppose a bucket contains stale entry A followed by live entry B. The example below isolates the index movement. It is an illustration of the algorithm, not a running OpenTelemetry SDK.

:::demo{name="bucket"}

## Change the traversal direction {#fix}

The merged fix walks each bucket backwards. When the callback removes the current entry, the entries that shift have already been visited. The next lower index still points at the next unvisited entry.

```java
for (int i = bucket.size() - 1; i >= 0; i--) {
  Entry<K, V> entry = bucket.get(i);
  action.accept(entry.key, entry.value);
}
```

This is a narrow guarantee: the callback can remove the entry it is currently visiting. It does not establish that arbitrary mutation, adding entries, or concurrent access is safe. Reversing a loop is not a general-purpose solution to collection mutation.

## Test the collision, then the consequence {#tests}

The map-level regression test uses two distinct keys with the same hash code. That forces them into the same bucket, independently of the map's capacity. During iteration, the callback removes the first entry it visits. The assertion checks that both keys were visited and that one entry remains.

The storage-level test exercises the consequence rather than only the loop. A first collection reports a set of series. On the next collection, only the even-numbered series report; the others become stale. The test checks that the collected attributes contain exactly the expected live series.

These tests answer different questions. One establishes that removing the current colliding entry does not skip another entry. The other checks that the metric storage path preserves live series when stale ones are removed.

:::note
A debugging question to keep
When data disappears during cleanup, inspect whether cleanup changes the collection that the traversal is still using.
:::

## Source and scope {#source}

This note is based on the public description, merged diff, and regression tests in [OpenTelemetry Java PR #8499](https://github.com/open-telemetry/opentelemetry-java/pull/8499), contributed by abdessattar23. The affected behavior described here is the reusable-data path; the PR identifies the immutable-data path, which uses ConcurrentHashMap, as unaffected.

No production incident, benchmark result, or permanent data-loss claim is implied.

[View the contribution record](/work/pooled-hashmap)


## 4. Speaking & Conference History

### The Future of Open Source Has New Faces
- **Event**: Devoxx Morocco 2026 (Casablanca, Morocco)
- **Status**: Delivered
- **Summary**: AI can lower the barrier to entering open source. Earning trust still requires understanding the work and taking responsibility for a contribution.

### When Observability Breaks: Four Bugs I Fixed in OpenTelemetry Java
- **Event**: OCX 2027
- **Status**: Proposal
- **Summary**: Submitted to OCX 2027. Acceptance is not confirmed.