@clebertsuconic You need to be a bit smarter here. If the TimedBuffer component is locked up, the broker can not sync() to disk. This will prevent the broker from shutting down gracefully. The component should shutdown with criticalIOError.
@mtaylor each TimedBuffer method is marked as synchronized and in particular the flush is being called by a background thread that could race with checkSize if the buffer isn't big enough: any of them could lead to potential deadlocks...
@franz1981 Those seem like good observations. Though not really related to this PR. The idea here is to add TimedBuffer to the critical analyzer, not solve any potential issues with the TimedBuffer itself. Perhaps you could open a new JIRA with the improvements you've suggested?
@clebertsuconic After looking into this, it starts getting rather complex, to catch all the edge cases in the various components. e.g. What happens if the shutdown thread is blocked as a component can't shutdown. Perhaps just a timeout on shutdown is enough to solve this problem. I have a test (still failing). Please take a look.
@mtaylor that's why we use halt by default... you can't shutdown the server if your device can't release a lock.
This task here is pretty simple.. just adding the CriticalAnalyzer to the timed buffer...
We can't go rogue and change this component that much. When you are syncing with AIO it's just for the time where the submit is being made. with NIO we could perhaps open the buffer to be written (it would be a very minor optimization) since the file itself can't be written while another thread is calling sync.