Very glad to hear that. Thanks! The plan is to start the 2.6.2 release procedure very soon.
On Tue, Jul 5, 2016 at 9:38 PM, Enric Jaen <enricj...@yahoo.es.invalid> wrote: > I tried the 2.6.2 snapshot and it works Thanks > > El Lunes 4 de julio de 2016 9:47, Remko Popma <remko.po...@gmail.com> > 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 <enricj...@yahoo.es.INVALID> 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 < > maire.anth...@gmail.com> 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 <remko.po...@gmail.com>: > > > >> 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 <enricj...@yahoo.es.invalid> > >> 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/@webapp.name@.log" > >>> 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 <boa...@gmail.com> > >>> escribió: > >>> > >>> > >>> That's the bug I was trying to find. It sounds related. > >>> > >>>> On 1 July 2016 at 23:09, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >>>> > >>>> Could this be the same issue as LOG4J2-1434? > >>>> > >>>> Ralph > >>>> > >>>>> On Jul 1, 2016, at 6:10 PM, Remko Popma <remko.po...@gmail.com> > >> 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 <enricj...@yahoo.es.INVALID> > >>> 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 < > >>>> remko.po...@gmail.com> 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 <enricj...@yahoo.es.INVALID> > >>> 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: log4j-user-unsubscr...@logging.apache.org > >>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >>> > >>> > >>> > >>> -- > >>> Matt Sicker <boa...@gmail.com > >>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > >
