Does logging with logaback impact anything?
*Java *: private static final Logger LOGGER =
LoggerFactory.getLogger(MyClass.class);
*Logback*:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
.................................................................
<appender name="karaf"
class="ch.qos.logback.classic.net.SyslogAppender">
<facility>LOCAL1</facility>
<syslogHost>localhost</syslogHost>
<suffixPattern>karaf: [%thread] %logger{36} - %msg%n</suffixPattern>
</appender>
.....................................
<logger name="com.mypackage.css" level="INFO" additivity="false">
<appender-ref ref="css2"/>
</logger>
</configuration>
We are using rsyslog running in same VM and writting logs using
*SyslogAppender.*
Our container is configured to use logback.
Noticed that after some tests logs are no longer written.
It has anything to do with this?
Srikanth Hugar
www.gharki.com
On Tue, Jul 21, 2015 at 5:36 PM, Jean-Baptiste Onofré <[email protected]>
wrote:
> I'm pretty sure the int[] also comes for the netty channel too ;)
>
> It sounds like the connection is not flushed or released.
>
> Regards
> JB
>
> On 07/21/2015 12:43 PM, Achim Nierbeck wrote:
>
>> Hi,
>> actually those 16million instances of ByteBuffer, SSLEngineResult and
>> EngineArgs are more worrying to me.
>> What is the scenario you run your applications with? Do you have so much
>> SSL requests coming in?
>>
>> regards, Achim
>>
>>
>> 2015-07-21 10:18 GMT+02:00 Jean-Baptiste Onofré <[email protected]
>> <mailto:[email protected]>>:
>>
>> The number of instances of int[] looks large for me (31% of the heap).
>>
>> Can you drill down the classes/threads which create those arrays of
>> int ?
>>
>> Regards
>> JB
>>
>> On 07/21/2015 10:05 AM, Srikanth Hugar wrote:
>>
>> Thank you.
>>
>> I have collected the heap dump and noticed lot of memory getting
>> consumed. I need to analyse.
>> Please find the attached image of the heap dump. Please let me
>> know if
>> your already aware of the issue.
>>
>> Srikanth Hugar
>> www.gharki.com <http://www.gharki.com> <http://www.gharki.com>
>>
>>
>>
>> On Tue, Jul 21, 2015 at 11:38 AM, Jean-Baptiste Onofré
>> <[email protected] <mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]>>> wrote:
>>
>> Hi Srikanth
>>
>> stopping a bundle will call the activator stop method of
>> the bundle,
>> but it won't remove the bundle classloader. You have to
>> uninstall
>> the bundle to actually remove
>>
>> I guess that you see heap consumption (not non heap), so it's
>> probably due object instantiation.
>>
>> If you take a heap dump or plug jvisualvm to Karaf, you
>> will see the
>> most instantiated objects and the ones which take most of the
>> memory. Then you will be able to identify (using the
>> package and
>> path), the bundle at the origin.
>>
>> Regards
>> JB
>>
>>
>> On 07/21/2015 07:50 AM, Srikanth Hugar wrote:
>>
>> Hello,
>>
>> I wanted to know whether is it possible to
>> check the bundle
>> memory usage.
>> I have the karaf running and more memory is getting
>> consumed.
>>
>> And also wanted to know if we stop the bundle in
>> running karaf,
>> is more
>> get released?
>>
>> I suspected one bundle consuming memory and i stopped the
>> bundle, but
>> memory not released.
>>
>> any information would be very helpful.
>>
>> Best Regards,
>> Srikanth
>>
>>
>> --
>> Jean-Baptiste Onofré
>> [email protected] <mailto:[email protected]>
>> <mailto:[email protected] <mailto:[email protected]>>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> [email protected] <mailto:[email protected]>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
>> & Project Lead
>> blog <http://notizblog.nierbeck.de/>
>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>
>>
>> Software Architect / Project Manager / Scrum Master
>>
>>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
