oscerd opened a new issue, #734:
URL: https://github.com/apache/camel-karaf/issues/734
## Description
Two separate points in
`core/camel-core-osgi/src/main/java/org/apache/camel/karaf/core/OsgiTypeConverter.java`.
### 1. `getDelegate()` is a non-atomic check-then-act
```java
public DefaultTypeConverter getDelegate() {
if (delegate == null) {
ensureTrackerOpen();
delegate = createRegistry();
}
return delegate;
}
```
`delegate` is `volatile`, which makes the read safe but does not make the
check-and-assign atomic. Two threads arriving together can both run
`createRegistry()`; one result is discarded, and anything registered against
the discarded instance in the interim is lost. `ensureTrackerOpen()` has the
same shape on the `trackerOpened` flag.
### 2. Discarding the delegate on loader removal is not surfaced
```java
public void removedService(ServiceReference<TypeConverterLoader>
serviceReference, Object o) {
...
ServiceHelper.stopService(this.delegate);
// It can force camel to reload the type converter again
this.delegate = null;
}
```
Any single `TypeConverterLoader` going away discards the whole delegate. The
rebuild in `createRegistry()` replays core converters plus the loaders the
tracker currently holds -- it cannot replay converters that were added
programmatically via `addTypeConverter` or by a Blueprint bean implementing
`TypeConverters`. Those disappear from a running context with nothing logged
above `trace`.
## Expected Behavior
`getDelegate()` creates the registry at most once per invalidation. When the
delegate is discarded and rebuilt, the fact that the rebuild cannot restore
programmatic registrations is visible in the log rather than silent.
## Actual Behavior
Concurrent first access can build the registry twice; converter loss on
rebuild is not reported.
## Additional Context
- The asymmetry with `addingService` is deliberate and must not be "fixed" by
making the two paths match. `d54f9a806` (#625, PR #684) specifically
reverted invalidate-on-add to loading into the existing delegate, precisely
to preserve programmatically-added converters. Any change here has to keep
that property.
- Genuinely replaying programmatic registrations on rebuild would mean
recording them as they are added, which is a larger design change than this
issue is proposing. Suggested scope here is the locking fix plus a warning
on rebuild; the replay question can be split out if it is worth doing.
---
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
