[JAVA-4242] Introduce Request Context support for API-agnostic context propagation Created: 19/Jul/21 Updated: 28/Oct/23 Resolved: 28/Sep/21 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Monitoring |
| Affects Version/s: | None |
| Fix Version/s: | 4.4.0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Mark Paluch | Assignee: | Jeffrey Yemin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | external-user, rp-toSched | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Documentation Changes: | Needed | ||||
| Description |
| Comments |
| Comment by Githook User [ 28/Sep/21 ] | ||||||||
|
Author: {'name': 'Jeff Yemin', 'email': 'jeff.yemin@mongodb.com', 'username': 'jyemin'}Message: Use correct MongoClientSettings in ContextProviderTest
| ||||||||
| Comment by Githook User [ 28/Sep/21 ] | ||||||||
|
Author: {'name': 'Jeff Yemin', 'email': 'jeff.yemin@mongodb.com', 'username': 'jyemin'}Message: Introduce RequestContext support for API-agnostic context propagation (#764)
| ||||||||
| Comment by Mark Paluch [ 26/Jul/21 ] | ||||||||
|
Thanks for raising the concern. Typically, there would be a parent span in the context that is used to create its children and children would be held separately. The code above should help to illustrate the calling side and is by no means exhaustive. | ||||||||
| Comment by Jeffrey Yemin [ 23/Jul/21 ] | ||||||||
|
mpaluch@paluch.biz one other issue: the CommandListener implementation in the description seems problematic. In the commandSucceeded method, "span" is removed from the request context, but I think that will cause problems if the Context is used more than once for a request (say to fully iterate a cursor). It seems like it needs to be able to push the parent span back onto the request context, so that it's available for the next event. Maybe span needs to be a Stack<Span> instead? | ||||||||
| Comment by Mark Paluch [ 23/Jul/21 ] | ||||||||
|
That makes sense. I initially hat Subscriber on my mind but then I went ahead with ContextView. Using Subscriber is the more flexible approach as a custom subscriber might provide custom means to transport contextual data. | ||||||||
| Comment by Jeffrey Yemin [ 23/Jul/21 ] | ||||||||
|
mpaluch@paluch.biz although we now have a dependency on Project Reactor for our implementation of the reactive streams driver, I'd like to avoid taking a dependency on it in our public API, which would be required by
I wonder if it would work to instead define the interface like:
Then an implementation of this interface can extract the Context from the Subscriber, e.g for ProjectReactor:
and return a RequestContext derived from the Context. Let me know if you think something like this would work. | ||||||||
| Comment by Mark Paluch [ 21/Jul/21 ] | ||||||||
|
All good, happy to elaborate.
Let me know whether that helps. Happy to discuss further aspects. | ||||||||
| Comment by Jeffrey Yemin [ 20/Jul/21 ] | ||||||||
|
Hi mpaluch@paluch.biz, thanks for opening this up. I have a few questions about the proposed API that perhaps you or someone else at Spring could ponder:
Apologies in advance for any misunderstanding I may have about this proposal. |