[ENHANCEMENT] [question] Is optimizely virtual thread / loom friendly? #537
Labels
acknowledged
The issue has been acknowledged and being looked into. Further details will follow.
Comments
|
I can see there is a bunch of synchronized methods which could be synchronized with ReentrantLock |
|
@jaeopt What a product should I choose? Am I reaally need to do that? To allow support of loom you need to allow to inject external executor service and replace synchronized blocks with ReentrantLock. |
|
@jaeopt any updates? |
|
@wyhasany You can submit a ticket for "Feature Experimentation" > "SDKs and Agent" in the link above. Not clear what we should change in the SDK to support Loom. We'll look into it. If you want, you can also consider to submit a PR for the enhancement with backward compatibility for Java8+. |
|
@wyhasany A new release (4.1.0) includes your PR to add this feature. Let us know if it works good for you. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
I wonder if optimizely is loom-friendly - e.g. does not pin the platform threads? I can see that you hardcode underneath platform thread, I would like to replace it with virtual one, currently I can do it only with nasty reflection
Benefits
Users of sdk can use its resources effectively. The very same goes for reactive apps.
Detail
No response
Examples
No response
Risks/Downsides
No response
The text was updated successfully, but these errors were encountered: