Controlling logging messages being output.

[scott_gardner]

We are getting a great volume of messages related to cupertino packet handling. Specifically log entries of the forms:

wowzastreamingengine_access.log:2015-07-29 11:39:55 PDT comment server INFO 200 - LiveStreamPacketizerCupertino.handlePacket[live-origin/definst/dev1-sd-1

and

origin_access.log:[INFO] 07/29/2015 14:00:33 - Successfully started cupertino for model dev1 for stream dev1-sd-1

These message types make up more than 50% of our log entries and do not contribute to our understanding of what is going. I would like to keep these out of the logs for the time being. In log4j, appenders can be set on a class basis to allow customizing the log output. I would like to do this for these messages, but I have not found anything in the documentation to help with log control at this level.

[Roger_Littin1]

Hi,

Wowza Streaming Engine logging extends the standard Log4j logger so that it can log the extra fields that are required for normal media server logging. In doing so, the normal log4j functionality that allows you to set specific appenders on a class based context have been replaced with an application based context. This means that you can specify different logging levels per Wowza application but not per Java class as you can with a regular application using log4j. You can configure context logging on a per application basis to set some applications at a lower level while retaining a higher level for other applications.

How to configure VHost and application context logging

If you set a different level for a specific context then it will also set the level for that context in the top level log files.

I would be very careful with lowering the logging levels as you lose a lot of useful information very quickly. Excessively large log files usually indicate some other underlying issue.

The first message that you have listed is printed when a stream starts and tells us all about the audio & video codec information for the stream. This should only be printed when a source stream starts or restarts so shouldn’t occur too frequently. If it is occurring frequently for the same streams then it may be indicating that there is some other underlying problem with the stream that is causing it to continuously reconnect and it should be investigated.

The second message doesn’t look like a normal Wowza Streaming Engine log message but looking at it, it appears to be telling us similar information to the one above.

Roger.

[Paul_Shields]

Hi,

Thank you for your feedback. I shall add your request for the ability to log based on classname to our backlog queue, but I can’t give any guarantees if or when this may be implemented.

Regards,

Paul

[scott_gardner]

Thank you for your response. You are right; the second logging message is from our code.

It is unfortunate that Wowza masks the log4j capability to log based on classname. That is a very useful capability and makes flexible logging for debug situations much more difficult. For our code it means that we have to go in and manually change log levels and even comment out logging code, because we cannot adjust class level logging though configuration. Our dev cycle can require a compile and deploy rather than editing log4j.properties (and maybe restarting the server). Removing a capability without replacing it with something more advanced is not what I would call progress.

Our application starts and stops streams frequently and the cupertino packet handler messages tends to spam the log files. A mechanism to stop this kind of message would be useful.