I tried the 2.6.2 snapshot and it works Thanks
El Lunes 4 de julio de 2016 9:47, Remko Popma <[email protected]>
escribió:
The fix for https://issues.apache.org/jira/browse/LOG4J2-1434 checks that any
large message increased the buffer size beyond the maximum. If it did then the
buffer is trimmed to the max size, so any large char[] arrays can be garbage
collected. Before the fix the reusable buffer could grow indefinitely.
Sent from my iPhone
> On 2016/07/04, at 17:17, Enric Jaen <[email protected]> wrote:
>
> Many thanks for the response, I will give a try from the git.
> What does the fix do? Do I need to use any flag? When is 2.6.2 planned to be
> released?
> Thanks also for the Async appender workaround
> Enric
>
> El Domingo 3 de julio de 2016 7:25, Anthony Maire
><[email protected]> escribió:
>
>
> Another possible way to investigate is to wrap your RollingFile appender in
> an Async appender. Since there is only one thread that outputs, if it is a
> thread local related issue, it should disappear (and it may be use as a
> workaround until the next release)
>
> 2016-07-02 16:10 GMT+02:00 Remko Popma <[email protected]>:
>
>> This issue may already have been fixed (see
>> https://issues.apache.org/jira/browse/LOG4J2-1434 ).
>> The fix will be in the upcoming 2.6.2 release.
>>
>> Can you verify if the problem still occurs with the current Log4j code in
>> git master?
>> Instructions on how to check out the latest source are here
>> <http://logging.apache.org/log4j/2.x/source-repository.html>. After that
>> you can build the binaries with the command
>> mvn clean install
>>
>> (Or mvn -DskipTests=true clean install if you are in a hurry.)
>>
>>
>> On Sat, Jul 2, 2016 at 5:24 PM, Enric Jaen <[email protected]>
>> wrote:
>>
>>> Sorry typo again, was 3GB (not 3MB) the total consumed memory by several
>>> char[]. For example I reveived a 60MB utf8 json and I see it resides
>> inside
>>> a 250MB char[]
>>> I have attached a dump screenshot
>>>
>>> Not sure if is relevant but I use RollingFile :
>>>
>>> <RollingFile name="PROJECT"
>>> fileName="${sys:catalina.home}/logs/@[email protected]"
>>> filePattern="${sys:catalina.home}/logs/@webapp.name@
>> .%d{yyyy-MM-dd}.log">
>>>
>>> <PatternLayout pattern="%d{ABSOLUTE} %-5p %mdc{ApiKeyOrEmail}-%mdc{tid}
>>> [%c{1}] %m%n"/>
>>> <filters>
>>> <ThresholdFilter level="@log.level.project@" onMatch="NEUTRAL"
>>> onMismatch="DENY"/>
>>> <MarkerFilter marker="API_RESPONSE" onMatch="DENY"
>>> onMismatch="ACCEPT"/>
>>> </filters>
>>> <TimeBasedTriggeringPolicy/>
>>> </RollingFile>
>>>
>>> I will try to reproduce if needed
>>>
>>>
>>>
>>> El Sábado 2 de julio de 2016 5:28, Matt Sicker <[email protected]>
>>> escribió:
>>>
>>>
>>> That's the bug I was trying to find. It sounds related.
>>>
>>>> On 1 July 2016 at 23:09, Ralph Goers <[email protected]> wrote:
>>>>
>>>> Could this be the same issue as LOG4J2-1434?
>>>>
>>>> Ralph
>>>>
>>>>> On Jul 1, 2016, at 6:10 PM, Remko Popma <[email protected]>
>> wrote:
>>>>>
>>>>> Yes, Java 7 or higher, so Java 8 is fine.
>>>>>
>>>>> I'm still trying to understand the problem. I understand that the
>>>> application receives and logs large JSON Strings.
>>>>> After that I don't understand.
>>>>> Are these strings 3MB long, and they cause Log4j to build up 250MB
>>>> buffers?
>>>>>
>>>>> Do you have a small program that demonstrates the problem?
>>>>>
>>>>> Remko
>>>>> Sent from my iPhone
>>>>>
>>>>>> On 2016/07/02, at 1:45, Enric Jaen <[email protected]>
>>> wrote:
>>>>>>
>>>>>> We use Java8 , is that ok?The problem is that we receive large json
>>>> responses and log4j is creating char[]'s of 250MB up a total of 3MB and
>>> we
>>>> are suffering of continuos full gc. By releasing that mem we would go
>>>> fine.Enric
>>>>>>
>>>>>>
>>>>>>
>>>>>> El Viernes 1 de julio de 2016 16:50, Remko Popma <
>>>> [email protected]> escribió:
>>>>>>
>>>>>>
>>>>>> Log4j 2.6.1 needs Java 7. Please provide more details about the
>>> memory
>>>> problem.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>> On 2016/07/02, at 0:38, Enric Jaen <[email protected]>
>>> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>> In our tomcat application we have a memory problem with logs kept
>> in
>>>> heap.I tried using log4j 1.6 and log4j2.enable.threadlocals = false but
>>>> without effect, what can be the reason?
>>>>>>> RegardsEnric
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>>
>>> --
>>> Matt Sicker <[email protected]
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
