/*
 * Licensed to the Apache Software Foundation (ASF) under one or more
 * contributor license agreements. See the NOTICE file distributed with
 * this work for additional information regarding copyright ownership.
 * The ASF licenses this file to You under the Apache license, Version 2.0
 * (the "License"); you may not use this file except in compliance with
 * the License. You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the license for the specific language governing permissions and
 * limitations under the license.
 */
package org.apache.logging.log4j.core.async;

import org.apache.logging.log4j.Level;

Policy for deciding whether to discard the event, enqueue it or log the event on the current thread when the queue
is full.

The asynchronous logging queue may become full when the application is logging faster than the underlying appender
can keep up with for a long enough time to fill up the bounded queue. When this happens, the logging subsystem has to
choose what to do with the event:


  
Enqueue the event. This will block until the background thread removes a log event from the queue and space for new events becomes available in the queue. There is a risk of causing deadlock here when the new logging call was made while processing another logging call, for example when Log4j calls toString() on a message parameter, and the parameter object makes a logging call from its toString() method.
  
Bypass the queue and send the event directly to the underlying appenders. This is the default policy used by Log4j since 2.7: see DefaultAsyncQueueFullPolicy. The benefit of this approach is that events will not get lost, but the disadvantage is that the resulting log file will be confusing for users, since log events will appear in the log file in random order: new events that are directly logged are followed by older log events taken from the queue.
  
Discard the event. Log4j offers a variation of this policy where log events that are more verbose than a certain threshold are discarded, and other events are sent to the underlying appenders. See DiscardingAsyncQueueFullPolicy for details.

 See AsyncQueueFullPolicyFactory for how to install a custom policy. 
See Also:
AsyncQueueFullPolicyFactory
Since:
2.6/**
 * Policy for deciding whether to discard the event, enqueue it or log the event on the current thread when the queue
 * is full.
 * <p>
 * The asynchronous logging queue may become full when the application is logging faster than the underlying appender
 * can keep up with for a long enough time to fill up the bounded queue. When this happens, the logging subsystem has to
 * choose what to do with the event:
 * </p>
 * <ul>
 *   <li>Enqueue the event. This will block until the background thread removes a log event from the queue and space for
 *     new events becomes available in the queue. There is a risk of causing deadlock here when the new logging call was
 *     made while processing another logging call, for example when Log4j calls {@code toString()} on a message
 *     parameter, and the parameter object makes a logging call from its {@code toString()} method.</li>
 *   <li>Bypass the queue and send the event directly to the underlying appenders. This is the default policy used by
 *     Log4j since 2.7: see {@link DefaultAsyncQueueFullPolicy}. The benefit of this approach is that
 *     events will not get lost, but the disadvantage is that the resulting log file will be confusing for users,
 *     since log events will appear in the log file in random order: new events that are directly logged are followed
 *     by older log events taken from the queue.</li>
 *   <li>Discard the event. Log4j offers a variation of this policy where log events that are more verbose than
 *     a certain threshold are discarded, and other events are sent to the underlying appenders.
 *     See {@link DiscardingAsyncQueueFullPolicy} for details.</li>
 * </ul>
 * <p>
 * See {@link AsyncQueueFullPolicyFactory} for how to install a custom policy.
 * </p>
 *
 * @see AsyncQueueFullPolicyFactory
 * @since 2.6
 */
public interface AsyncQueueFullPolicy {

    
Returns the appropriate route for the current log event, given the specified parameters.
Params:
backgroundThreadId – the thread ID of the background thread. Can be compared with the current thread's ID.
level – the level of the log event
Returns:
the appropriate route for the current event/**
     * Returns the appropriate route for the current log event, given the specified parameters.
     *
     * @param backgroundThreadId the thread ID of the background thread. Can be compared with the current thread's ID.
     * @param level the level of the log event
     * @return the appropriate route for the current event
     */
    EventRoute getRoute(final long backgroundThreadId, final Level level);
}