🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Java RTO Context Handle Busy Spin
Hi,
I have allocated core while initializing Context Handle but it doesn't keep the core busy and due to this first message is always has high end to end latency. How can I keep Context Handle on busy spin ? My Java RTO is version 7 and Java 11.
Best Answer
-
Yeah, the callback is synchronous, on the API's context thread. There's some pictures in the docs here: https://docs.solace.com/API/API-Developer-Guide/API-Threading.htm
So what you could be measuring is some log4j initialization thing? To help verify, maybe you could try initializing a large array, and then all that the callback does is delta the current time from the message's time, and stick that in the next slot in the array.
Note that there could be some amount of JVM warm-up that could contribute as well. Even CPU caching level stuff. When doing latency testing with native C API, with C code, we generally do a small warm-up (i.e. throw away the first number of messages) before starting the measurements. So... yeah it might be hard to completely reduce some amount of latency on the first messages. Try removing the log4j stuff and just record the deltas in a pre-defined array. Wondering if that helps.
1
Answers
-
I think my core allocation is incorrect, I have specified core as 4 but looks like I need to provide bitmask.
0 -
@mprabhat_jha I don't believe this is possible..? I'm not 100% sure, but I can ask internally.
It also might be possible that your initial latency on first message is due to JVM hotspot optimization. When I've run latency checks with other Java APIs, I run for a warm-up period first to obtain best latency measurements.
How are you measuring latency? Are all following messages fast? Or, at least faster? Any chance of sending a batch of test or dummy messages when first connecting to ensure you've "warmed up" properly..?
0 -
@Aaron sorry had been busy past few days and delayed on this thread. Latency is being measured from the time my onMessage is getting called. I am using DirectPublisher. First few message always have high latency and then it becomes smooth.
I am using Log4j2 Aynch logger but it appears that any logging done in on onMessage method is handled in solcontext-thread, even though log4j2 already has its separate thread. All other places in my application log formatting and logging is done in log4j thread but only the onMessage method has this issue.
0 -
Thinking through it makes sense. Solcontext is a JNI thread and it's invoking the callback, and callback runs in the calling thread.
The callback is executed synchronously or asynchronously? If its synchronous then all messages will wait till I process the current one.
0 -
Yeah, the callback is synchronous, on the API's context thread. There's some pictures in the docs here: https://docs.solace.com/API/API-Developer-Guide/API-Threading.htm
So what you could be measuring is some log4j initialization thing? To help verify, maybe you could try initializing a large array, and then all that the callback does is delta the current time from the message's time, and stick that in the next slot in the array.
Note that there could be some amount of JVM warm-up that could contribute as well. Even CPU caching level stuff. When doing latency testing with native C API, with C code, we generally do a small warm-up (i.e. throw away the first number of messages) before starting the measurements. So... yeah it might be hard to completely reduce some amount of latency on the first messages. Try removing the log4j stuff and just record the deltas in a pre-defined array. Wondering if that helps.
1
