Akhil, Appenders of type "org.apache.log4j.FileAppender" do not compress log files. Thus, it means, that "ArchivingFileAppender" (of type QpidCompositeRollingAppender ) is causing the issue. Potentially, removal or replacement of this appender with any suitable FileAppender (for example, DailyRollingFileAppender or RollingFileAppender or any other log4j file appender) might fix the issue.
> You mean to say that we should change Log4j and use > slf4j instead. > Yes presently we are using Log4j as appender and we have set the > logging_level="info". Does changing it to only error will help? sl4j is a logging framework used in newer versions of qpid brokers (6.0 and above). You cannot use it with 0.32 version of Qpid Broker. In 6.x brokers logging configuration is stored in broker own configuration. "FileAppender" is a separate appender. "FileAppender" and "Archiving FileAppender" logs into different files separately from each other. "FileAppender" does not compress its log files, whilst "Archiving FileAppender" does it. Changing log level on "FileAppender" to "error" will not help with the issue. Removal or replacement of "ArchivingFileAppender" ( QpidCompositeRollingAppender ) should fix the issue. Kind Regards, Alex On 19 June 2017 at 14:13, Akhil Samnotra <[email protected]> wrote: > Also , we are using > appender class="org.apache.log4j.QpidCompositeRollingAppender" > name="ArchivingFileAppender"> > <!-- Ensure that logs always have the DatePattern appended to the > filename. > DEFAULT IF NOT CONFIGURED: true --> > <param name="StaticLogFileName" value="true"/> > <param name="file" > value="${QPID_WORK}/log/${logprefix}qpidlog${logsuffix}.log"/> > <!-- Style of rolling to use, by: > File Size(1) > Date(2) > Both(3) > > When Date (or Both) is enabled then the value of DatePattern > will determine > when the new file is made. e.g. a DatePattern of > "'.'yyyy-MM-dd-HH-mm" > which includes minutes will cause a new backup file to be made > every minute. > > DEFAULT IF NOT CONFIGURED: 3 --> > <param name="RollingStyle" value="3"/> > <!-- Set the count direction: > Negative numbers mean backups are numbered <latest>, .0, .1, > .2,..., .n > 0 means backup is DatePattern stamped and followed with a > Positive number > if the DatePattern stamp clashes with other existing > backups. > Positive numbers mean backups are numbered 0, 1, 2, ..., n, > <latest> > > DEFAULT IF NOT CONFIGURED: -1 --> > <param name="CountDirection" value="0"/> > <!-- Maximum File Size: > DEFAULT IF NOT CONFIGURED: 10MB --> > <param name="MaxFileSize" value="10000"/> > <!-- Date Pattern: > DEFAULT IF NOT CONFIGURED: "'.'yyyy-MM-dd" --> > <param name="DatePattern" value="'.'yyyy-MM-dd-HH-mm"/> > <!-- Maximum number of backup files: > 0 means no backups > -1 means infinite backups > > DEFAULT IF NOT CONFIGURED: 0 --> > <param name="MaxSizeRollBackups" value="1000"/> > <!-- Compress(gzip) the backup files to the backup location: > DEFAULT IF NOT CONFIGURED: FALSE --> > <param name="CompressBackupFiles" value="true"/> > <!-- Compress the backup files using a second thread: > DEFAULT IF NOT CONFIGURED: FALSE --> > <param name="CompressAsync" value="true"/> > <!-- Backup Location: > DEFAULT IF NOT CONFIGURED: same dir as log file --> > <param name="backupFilesToPath" value="${QPID_WORK}/log/backup"/> > > <layout class="org.apache.log4j.PatternLayout"> > <param name="ConversionPattern" value="%d %-5p [%t] (%c{2}) - > %m%n"/> > </layout> > </appender> > > We are presently using this configuration in Log4j.xml. > > Can you please help? > > Thanks > Akhil Samnotra > > > On Mon, Jun 19, 2017 at 6:40 PM, Akhil Samnotra <[email protected]> > wrote: > > > Hi , > > Thanks for the help . You mean to say that we should change Log4j and use > > slf4j instead. > > Yes presently we are using Log4j as appender and we have set the > > logging_level="info". Does changing it to only error will help? > > > > This is the present configuration : > > > > <appender class="org.apache.log4j.FileAppender" name="FileAppender"> > > <param name="File" value="${QPID_WORK}/backuplogs/${logprefix} > > qpidmaster${logsuffix}.log"/> > > <param name="Append" value="true"/> > > > > <layout class="org.apache.log4j.PatternLayout"> > > <param name="ConversionPattern" value="%d %-5p [%t] (%c{2}) - > > %m%n"/> > > </layout> > > </appender> > > > > Can we do anything in this configuration to get rid of the issue? > > > > Thanks > > Akhil > > > > On Mon, Jun 19, 2017 at 6:31 PM, Oleksandr Rudyy <[email protected]> > wrote: > > > >> Hi Akhil, > >> > >> Thanks for raising JIRA and attaching the screenshots from MAT. > >> As per screnshot [1] it seems that heap memory was consumed by > >> java.io.File > >> objects. Judging by the file names, the file objects were created by log > >> appender whilst compression broker logs. > >> > >> What type of file appender are you using with Qpid Broker? Is it > >> "org.apache.log4j.QpidCompositeRollingAppender"? You can check > >> ${QPID_HOME}/etc/log4j.xml for logging configuration? > >> We are not aware about any defect in QpidCompositeRollingAppender which > >> would manifest in heap memory consumption by java.io.File objects. > >> > >> The broker logging functionality in version 0.32 is based on log4j . It > >> was > >> replaced with slf4j and logback in following 6.x versions. > >> You can consider migration to newer version of broker (6.1.3 at the > moment > >> of writing this email). If migration of broker is not an option, you can > >> try replacing the log appender with another one. > >> > >> > >> Kind Regards, > >> Alex > >> > >> > >> [1] https://issues.apache.org/jira/browse/QPID-7828 > >> [2] https://issues.apache.org/jira/secure/attachment/ > 12873368/image1.PNG > >> > >> > >> On 19 June 2017 at 11:46, Akhil Samnotra <[email protected]> > wrote: > >> > >> > HI , > >> > I have even raised the jira but didnt got any resolution. > >> > > >> > Thanks > >> > Akhil > >> > > >> > On Mon, Jun 19, 2017 at 1:47 PM, Oleksandr Rudyy <[email protected]> > >> wrote: > >> > > >> > > Hi Akhil, > >> > > > >> > > The screenshots did not get through with your latest email. Could > you > >> > > please try raising JIRA and attaching the screnshots to it? > >> > > > >> > > Kind Regards, > >> > > Alex > >> > > > >> > > On 17 June 2017 at 06:04, Akhil Samnotra <[email protected]> > >> > wrote: > >> > > > >> > > > hi , > >> > > > > >> > > > please find the screenshots attached. > >> > > > thanks > >> > > > > >> > > > Akhil > >> > > > > >> > > > On Sat, Jun 17, 2017 at 1:52 AM, Oleksandr Rudyy < > [email protected]> > >> > > wrote: > >> > > > > >> > > >> Hi Akhil, > >> > > >> It seems attachments have been stripped off. Could you please > >> resend > >> > > them > >> > > >> or raise a JIRA [1] and attach your screenshots to the JIRA? > >> > > >> > >> > > >> Kind Regards, > >> > > >> Alex > >> > > >> > >> > > >> [1] https://issues.apache.org/jira/projects/QPID > >> > > >> > >> > > > > >> > > > > >> > > > > >> > > > ------------------------------------------------------------ > >> --------- > >> > > > To unsubscribe, e-mail: [email protected] > >> > > > For additional commands, e-mail: [email protected] > >> > > > > >> > > > >> > > >> > > > > >
