I currently have my Java ATS set up to receive live data from IQ's socket and then distribute it to various LinkedBlockingQueues, each of which has it's own consumer thread. Each of ~1000 symbols is assigned to one of the queues. Doing it this way (and not using a thread pool) simplified a lot of concurrency headaches. I realize this has a cost in terms of efficiency but I'm okay with that for now.
That said, I'm considering switching from this approach to one where I set up multiple sockets (each with their own reader thread) instead of using queues, and having the IQFeed app do the work of marshalling the ticks to the correct socket. Is there an obvious answer to which approach would have better performance?
The other motivation for doing this is that I'm assuming if IQFeed moves to a multithreaded live feed at some point, it will be implemented the same way as the historical currently is with multiple sockets concurrently fed.
That said, I'm considering switching from this approach to one where I set up multiple sockets (each with their own reader thread) instead of using queues, and having the IQFeed app do the work of marshalling the ticks to the correct socket. Is there an obvious answer to which approach would have better performance?
The other motivation for doing this is that I'm assuming if IQFeed moves to a multithreaded live feed at some point, it will be implemented the same way as the historical currently is with multiple sockets concurrently fed.