Even if one properly addresses the obvious synchronization problems in the example (Thread.sleep is not a synchronization mechanism), the SynchronizedQueue case may lose events. The BlockingQueue.offer contract states that the method returns immediately if space is not available in the queue. In the case of SynchronizedQueue, "space is available" only when another thread is blocked in the BlockingQueue.take method. This implies that while the service thread is sending the event to the remote receiver, events offered to the queue will be silently dropped. We could improve on this a bit by specifying a timeout for BlockingQueue.offer – this would allow a little tolerance for a slow remote receiver without unduly blocking up the appender's calling thread.

All of that said, it should still be noted that SocketAppender/Receiver is a best effort mechanism. Log events could be lost for many reasons (e.g. transient network failure). If you want a lossless remote logging appender, you should use a transactional mechanism – e.g. database or JMS with transacted session support.