4 ms·
I don’t really follow the way you define terms here. Concurrently means processing at the same time, if work is held in a queue it’s not being processed. If you
by hilbertseries 5y ago
I don’t really follow the way you define terms here. Concurrently means processing at the same time, if work is held in a queue it’s not being processed. If you reduce the number of threads to 1 and leave the queue at 10k. You’re claiming that this is concurrently processing 10k messages, but you only have one thread. Is the idea here that you’ve reimplemented scheduling on top of the jvm? This is exactly what project loom is trying to protect the developer from having to do.
- vemv 5y agoAs long as there's more than 1 thread processing the queue, the queue is being concurrently processed. Particularly, the queue items will be picked up in a nondeterministic order, driven by CPU utilization. > Is the idea here that you’ve reimplemented scheduling on top of the jvm? No, I'm implementing a fairly vanilla pipeline pattern, just with simpler, more explicit blocks than those used by async frameworks/abstractions. IIRC it's described well in the JCIP book.
- closeparen 5y agoIt sounds like you're talking about a CPU-heavy workload. In this context often it's an IO-bound workload; the service makes upstream requests to a database and other services. Most of the request lifetime is waiting for responses. To get reasonably many requests started and waiting on those responses, either you need to write in async/callback oriented style, or you need a mechanism to make many thousands of naive, blocking routines coexist efficiently.