Project

General

Profile

Queue Overflow events: proposal to increase a log level

Igor Khomenko
Added almost 4 years ago

Hi guys,

Was testing a lot Tigase under the high load and found that Queue Overflow events don't have so hight log level

Look at AbstractMessageReceiver class

        try {
            out_queues.get(queueIdx).put(packet, packet.getPriority().ordinal());
            ++statSentPacketsOk;
        } catch (InterruptedException e) {
            ++statSentPacketsEr;
            if (log.isLoggable(Level.FINEST)) {
                log.log(Level.FINEST, "Packet dropped for unknown reason: {0}", packet);
            }

            return false;
        }    // end of try-catch

and

        try {
            in_queues.get(queueIdx).put(packet, packet.getPriority().ordinal());
            ++statReceivedPacketsOk;
        } catch (InterruptedException e) {
            ++statReceivedPacketsEr;
            if (log.isLoggable(Level.FINEST)) {
                log.log(Level.FINEST, "Packet dropped for unknown reason: {0}", packet);
            }

            return false;
        } 

And let's say we enabled only logs with a level SEVER in init.properties:

--debug = server
basic-conf/logging/tigase.server.level=SEVERE

In that case and in case of queue overflow we won't be able to catch this problem via logs

Is it possible to change those logs from FINEST to SEVERE level or it doesn't make any sense?


Replies (1)

Avatar?id=6023&size=32x32

Added by Artur Hefczyc TigaseTeam almost 4 years ago

Increasing log level in here would be actually very harmful. Please note, queue overflow happens when the server is under a load higher than it can handle, which means thousands of packets per second. Once queue overflow starts to happen it usually happens for great number of packets. Putting heavy logging in this part of the code would mean you potentially get thousands of log records per second. This would lead to further performance degradation of the system and even higher number of packets lost due to queue overflow and a higher number of log records.

The best way to watch the system and detect any performance issues and bottlenecks is through the server statistics. You have over one thousand of different load and performance metrics on the server. Retrieving these metrics even once a second does not generate significant load and you get very accurate picture of what is going in the server. You also get a number of packets lost due to queue overflow.

    (1-1/1)