[
https://issues.apache.org/jira/browse/LOG4J2-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890997#comment-15890997
]
Kim Northrop commented on LOG4J2-1761:
--------------------------------------
The asynchronous logger improves the logging performance because much of the
work isn't done in the calling thread but asynchronously. This performance
improvement is independent of the queue implementation, and it would be good if
all users could benefit from it, even those who do not want to use the
disruptor. I am one of these users because, first, I do not want to reserve so
much memory for logging (but I don't know in advance how many places are needed
in the queue). And secondly, I am irritated about the errors in the disruptor
class method MultiProducerSequencer.next(int), the method which is responsible
for reserving the next indices where elements will be stored. I attach the code
(current GitHub version) below.
The method does not handle overflow: it is not true that
wrapPoint > cachedGatingSequence
when new elements cannot be stored, the correct test is
wrapPoint - cachedGatingSequence < 0
(think about what happens when the indices of the readers reach Long.MAX_VALUE
and are incremented once more but wrapPoint has not reached Long.MAX_VALUE yet)
The same applies to the update of cachedGatingSequence.
Moreover computing and setting cachedGatingSequence in this way is wrong.
I describe these errors here and not at the disruptor's project site because I
do not want to use the disruptor anyway. However, I would like to use the
asynchronous logger, but with a different queue.
public long next(int n)
{
if (n < 1)
{
throw new IllegalArgumentException("n must be > 0");
}
long current;
long next;
do
{
current = cursor.get();
next = current + n;
long wrapPoint = next - bufferSize;
long cachedGatingSequence = gatingSequenceCache.get();
if (wrapPoint > cachedGatingSequence || cachedGatingSequence >
current)
{
long gatingSequence = Util.getMinimumSequence(gatingSequences,
current);
if (wrapPoint > gatingSequence)
{
waitStrategy.signalAllWhenBlocking();
LockSupport.parkNanos(1); // TODO, should we spin based on
the wait strategy?
continue;
}
gatingSequenceCache.set(gatingSequence);
}
else if (cursor.compareAndSet(current, next))
{
break;
}
}
while (true);
return next;
}
> Support for standard java queues for the async logger
> -----------------------------------------------------
>
> Key: LOG4J2-1761
> URL: https://issues.apache.org/jira/browse/LOG4J2-1761
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.7
> Reporter: Kim Northrop
> Priority: Minor
> Attachments: AsyncLogEvent.java, AsyncLoggerWithQueueContext.java,
> AsyncLoggerWithQueueContextSelector.java, AsyncLoggerWithQueue.java,
> QueueWrapperCLQ.java, QueueWrapper.java, QueueWrapperLBQ.java,
> QueueWrapperLTQ.java
>
>
> Please add support for standard java queues (LinkedTransferQueue,
> ArrayBlockingQueue, LinkedBlockingQueue, ConcurrentLinkedQueue) to the async
> logger. I will attach some classes for usage with System properties
> (Log4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerWithQueueContextSelector,
> LoggerQueue.Capacity=<capacity>, LoggerQueue.Type=<currently one of
> LinkedTransferQueue, ConcurrentLinkedQueue, LinkedBlockingQueue>). Since most
> of these queues allocate new nodes for new elements I have not implemented
> usage of thread locals for the log events.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
