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]
>> > > >
>> > >
>> >
>>
>
>
