Open pablosaavedra-rappi opened 1 year ago
Hi Pablo, we will review this with our engineering team and report back.
Hi @Pablo,
I submitted the Feature Request, our product managers go through the new features backlog frequently and will decide if it will be included in a certain version. We do post all new features in our New Releases page (https://www.split.io/releases/) when they are released, I recommend to subscribe to the page for new updates.
I am closing this ticket for now, please let me know if you have any questions, we can re-open it anytime.
Thanks Tin Tran
Thanks, any way to know whether the feature actually makes it to the backlog?
Hi @pablosaavedra-rappi,
First of all sorry for the delay on this feature support. After some analysis and PoCs our decision is to add the option to use Virtual Thread for customers that are using java 19 and above in our configs. To keep supporting older versions of Java we added the possibility to attach a ThreadFactory into SDK threadFactory
config. With this option, you are able to pass a ThreadFactory
defined as Virtual Threading. Otherwise, we default to the non virtual thread.
Below is an example of how handle it with Virtual Threading,
SplitClientConfig config = SplitClientConfig.builder()
.threadFactory(Thread.ofVirtual().factory())
.build();
SplitFactory splitFactory = SplitFactoryBuilder.build("YOUR_API_KEY", config);
SplitClient client = splitFactory.client();
We release a rc version if you want to try which is 4.8.0-rc
. If this works for you, we are going to make an official release.
Thanks!
Thanks Mati, I'll see where can we integrate this new version and give it a try. Will keep you posted on results.
With the release of Java 19 and the preview of virtual threads, it would be nice to be able to provide a ThreadFactoryBuilder implementation so that applications that are using virtual threads could do so without adding a strong dependency with a preview feature.
Why would it be nice to have the capability? The Split SDK creates a number of background threads for synchronization purposes. Since all the threads are daemon and they spend most of the time in WAITING or TIMED_WAITING, it would be a great use case for virtual threads instead of having several OS threads.
Attached a screenshot of a thread dump with an example
Thanks.