Public Attributes | |
int | nFlush |
List< LogRecord > | logRecords |
Package Functions | |
TestLogQueue () | |
void | reset () |
Future< Boolean > | flush () |
synchronized boolean | log (LogRecord logRecord) |
log
and flush
. Actually this class does not support any of the special features of DispatchingLogQueue. It will not even forward the log record to it. It only extends DispatchingLogQueue because AcsLoggingHandler requires a DispatchingLogQueue in the ctor and I see no big advantage in refactoring this.
|
|
|
Tries to send log records to the remote log service, but at most RemoteLogDispatcher#getBufferSize(). If sending fails, the log records remain in the queue (actually they may be first taken out and then get re-submitted).
This method returns immediately, since flushing is done in a separate thread. The returned future object can be used to wait for termination of the log flush and get the result, or to cancel the flush. The result is a Reimplemented from alma::acs::logging::DispatchingLogQueue.
|
|
Adds a Threading note: it seems ok to make this method "synchronized". This avoids problems with stale queue size, even though the damage would be small since the treatment of queue size is somewhat arbitrary anyway. Synchronization should not block callers long at all because flushing is done in a separate thread and only gets triggered here. TODO: there is currently a minor problem with queue overflow: log records get drained from the queue, and when they can't be sent off to the log service, they are resubmitted to the queue. It could happen that in the meantime, some other record with INFO or higher level has been added to the queue, and that resubmitting some of the even more important records may fail. The solution would be to replace the 70%-filter rule with a running priority filter: any incoming record can kick out a less important record if the queue is full.
Reimplemented from alma::acs::logging::DispatchingLogQueue.
|
|
|
|
|
|
|