@SylvainBoisse Yeah. It was a mistake on my end that I didn't made naming thing clear. Thanks for pointing that out, I will fix that. I also saw your edit and now I understood what needs to be done to avoid business thread and pinger thread to work on same socket.

I have one question on your edit though, I still see you are using synchronized on a socket. Do we still need that? Since now we are using polling from priority queue for all the business thread and pinger thread also will be working on different socket so do we need synchronized now?

Also just to make things clear, I don't do anything special to revive dead socket in my code, I just need to keep pinging them until I get acknowledgment back. When I say dead socket, then it generally means, the messaging queue machine on which socket was open is down or messaging queue app is dead.

So I will keep pinging a socket until I get the acknowledgment back and then it means socket is back online. Anyway, I think I got overall idea now, just that have one question on that synchronized thing as of now.

Also I came up with different approach of solving the same problem which uses same concept of BlockingQueue as you suggested and it also considers some of your points as well I think. I am creating a SocketPool for each datacenter where I ping only dead sockets to check whether they are live or not.

And then I am exposing methods where I can poll socket for business thread to use, release sockets back to queue, also report dead socket by taking a look at the acknowledgment (as you mentioned in this question).

So this new approach will expose all these methods where I can properly poll socket, release socket and report back dead socket from business thread. But somehow I feel like, I didn't got everything right from design perspective or maybe there might be some thread safety issues as well.

I think you will like this solution better so wanted to see if you can take a look at that as well and see what we can do to improve and make it better. In this solution I only ping dead sockets (reported by business thread) from pinger thread to check whether they are alive now or not? If they are alive, then only I will add them back to liveQueue.

After I get this thing simplified, only thing we need to do is calling those api's properly from SendToQueue class for polling, releasing and reporting back dead socket which is easy. Here is my question:

Yeah i'm still using synchronized although no two thread should have a handle to the same socket. It's superfluous indeed. But if it really is, then it is also cheap (lock obtained almost instantaneously, no competition, no retries etc.) so I would keep it as a last barrier (in case the algo has a bug or for future evolutions)

understood for revival. Now that you mention that sockets are long-lived, with a complex state (dead/alive, but also idle/sending/waiting for ack) I am thinking m alternative idea of having smarter sockets that handle and manage their own state is even better than a centralized entity managing from above.

that would allow speed-up for business threads (no waiting for ack) while still being more responsive (getting ack asynchronouslyeven after business messages are sent)

i'll try to look at your other Q as well

man you're busy over the christmas holdays ^^

@SylvainBoisse Yes sockets are long-lived. They will only be down when the machine on which messaging queue is running is down or messaging queue app is dead. Once either of these two things are fixed, they will be back online and start giving acknowledgment back. What I do is, I keep sending message asynchronously and if acknowledgment is not received then I retry again to send and keep retrying until I get the acknowledgment back.

I already have a code review question on this shared above. As of now it doesn't have a way to determine which sockets are dead if acknowledgment is not received but I am working on it.

@SylvainBoisse lol yeah, I am working at night and holidaying in the morning. :)

Sorry for bothering you in this holiday period btw.

Idea is very simple, I need to make sure, I don't share same socket between two threads at all - either two business thread or one business thread and other pinger timer thread for live socket check.

And if any socket is dead, then I don't want business thread to use that socket to send data on it. And as soon as dead socket is back online, add them back to liveQueue so that business thread can start using them. So either I can keep pinging all available sockets to check whether they are live or not and basis on that I can add them back to liveQueue or just ping dead sockets (reported by business thread) to see whether they have become live or not.