I'm currently designing a server with the following structure:
- A TCP thread pool that receives data from the network
- A queue that holds these requests
- A worker thread pool of a fixed size that takes requests from the queue and executes some work where a
ConcurrentHashMap
is read, and results analyzed. After the work is complete, the results are posted to a write queue. - The write queue stores write requests for
ConcurrentHashMap
- A write thread pool of a fixed size that takes requests from the write pool and writes them to the
ConcurrentHashMap
Server constraint:
- For a particular entry in
ConcurrentHashMap
, a write will get posted to the network several seconds before a read gets posted to the network. The threads must never allow the read to get scheduled before the write occurs.
My ideas so far:
- First, I'm hoping that the 3-5 seconds or so is a big enough head start for a write to get through before the read
- Set the write threads to have high priority and the read threads to have low priority
- A read can check the last write time, and if large enough (like several minutes or hours ago), it knows to ignore the last write because it is out of date. However, it then knows that it can't make an informed decision. I could have the thread retry like twice in the case of an outdated entry, but this feels clumsy.
- Added the write queue so that the TCP pool can post directy to the write queue (write requests don't need to be processed by the worker pool) instead of the job queue while read requests are put in the worker thread queue, and then post some logging info to the write queue later. after the worker pool
Are there any ways to ensure that reads have a low chance of occurring before a write or are the precautions I've already taken sufficient? Should I use the read retry mechanism?
Also, is a write queue actually needed or can I just use worker threads more generally to also handle writes? Write order is not important.