There is two potential minor thread safety issues with org.jboss.resteasy.plugins.providers.sse.SseEventOutputImpl:

Case 1
SseEventOutputImpl should better use internal lock object instead of synchronizing the method itself to prevent starvation and deadlock situations.
For example let's consider that a given SseEventOutputImpl is both registred in a SseBroadcaster and also used in another treatment. Let's suppose that T1 thread is running this treatment as follow and T2 thread is responsible of broadcasting incoming event:

T1:
   public void process()
   {
	   synchronized (sseEventSinkIntance)
	   {
		   while (true)
		   {
			   ...
		   }
	   }
   }

In this case because of the synchronized applied directly on SseEventOutputImpl methods , T2 will enter an endless wait, waiting for T1 to release the lock in order to broadcast the message to all regsitered SseEventSink.

Case 2
Let's consider that we are running on a server that does not support real asynchronous mechanism and that a given SseEventOutputImpl is shared between 3 threads:

• T1 is the request thread, it invokes resource method then invokes SseEventOutputImpl.flushResponseToClient() when the resource method exits. Then because of the fake asynch mechanism, it waits for notification (SseEventOutputImpl being closed for example*) to go on and exit.

• T2 thread invokes SseEventOutputImpl.send(). It takes a pause for thread scheduling purpose at line L137 before invocation of SseEventOutputImpl.writeEvent(...)

• T3 thread invokes SseEventOutputImpl.close() successfully and exits.

• T1 thread receives notification to finish request processing and release response output stream. Then the underlying http server manipulate the output stream to close it at the end.

• T2 thread resumes, it manipulates the response outpoutstream at the same time T1 is manipulating it too => This case leads us to concurrent access to non thread safe outputstream