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
>

Reply via email to