0

Actually, I receive a message through RabbitMQ which is large. While consuming this message, we log it.

logger.info("payload: {}", payload);

I see the following exception in logs at the logger statement line.

Caused by: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:3332) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137) at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:421) at java.lang.StringBuffer.append(StringBuffer.java:272) at org.apache.log4j.helpers.PatternParser$LiteralPatternConverter.format(PatternParser.java:419) at org.apache.log4j.PatternLayout.format(PatternLayout.java:506) at org.graylog2.GelfMessageFactory.makeMessage(GelfMessageFactory.java:37) at org.graylog2.log.GelfAppender.append(GelfAppender.java:220) at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251) at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66) at org.apache.log4j.Category.callAppenders(Category.java:206) at org.apache.log4j.Category.forcedLog(Category.java:391) at org.apache.log4j.Category.log(Category.java:856) at org.slf4j.impl.Log4jLoggerAdapter.info(Log4jLoggerAdapter.java:324)

After getting rid of the logger statement, the message was processed successfully.

So, can I be sure that the logger was causing the OutOfMemoryError? Or it is something else that is causing the OutOfMemoryError?

Heap size is : 2048M

Sreeja Mohan
  • 135
  • 2
  • 6
  • 1
    Sure looks like it. What size is your heap space? Try assigning more heap space to the JVM using the -Xmx parameter . – daZza Jul 06 '16 at 08:18
  • Possible duplicate of [Increasing heap space in eclipse: (java.lang.OutOfMemoryError)](http://stackoverflow.com/questions/8600972/increasing-heap-space-in-eclipse-java-lang-outofmemoryerror) – Jordi Castilla Jul 06 '16 at 08:25
  • @JordiCastilla probably not. OP is just asking for assistance to verify whether is it the `logger` object the cause of OutOfMem exception. – Samuel Toh Jul 06 '16 at 08:30
  • Rise your heap space, or try : `logger.info("payload: "+ payload)`; – J.Mengelle Jul 06 '16 at 08:31
  • 1
    @SamuelToh IMO a 90mb log message shouldn't cause the error... but that is just my opinion.... – Jordi Castilla Jul 06 '16 at 08:34
  • 1
    @JordiCastilla - yep 90mb is considered relatively small to a machine but strangely it is failing on the `Arrays.copyOf` api. Either OP's jvm really has got a real small heap size or maybe the `copyOf` api could have gotten into an infinite loop which cause heap to run out? – Samuel Toh Jul 06 '16 at 08:40
  • 1
    Outside the fact that it is causing such an error: Is logging every message content as "info" really useful? I'd consider that a performance bottleneck. I guess though, you cannot simply ditch the line, so you maybe want to perform a size-check and cut the message for log-output into smaller chunks or log only the first chunk. – Fildor Jul 06 '16 at 08:55
  • 1
    This looks like an XY Problem. There is no good reason to log an entire message. Why do you do this? – Raedwald Jul 06 '16 at 08:56
  • 1
    Indeed. Logging the entire payload is not a good approach here but note that this is potentially an incomplete code. Maybe the final version could be something like `if debugLevel == "everything"` then do so? @Raedwald, yes it can potentially be a performance bottleneck as this sort of operation can chew up disk I/O or CPU easily. – Samuel Toh Jul 06 '16 at 08:59
  • Max heap size is 2048M. Even I think that logging the entire payload is unnecessary hence got rid of it. But, I just wanted to confirm if logging could cause such error. I would like to thank everyone for responding to my question quickly. – Sreeja Mohan Jul 06 '16 at 09:47

3 Answers3

2

Q: So, can I be sure that the logger was causing the OutOfMemory error? Or it is something else that is causing the OutOfMemory Error?

A: Based on the stack trace, yes.

From the trace you can evidently see that your log4j module (which is the logger object) was trying to perform a copyOf() operation but before the copy was done the program died with OutOfMemoryException.

As to how you would generally read the stack trace, this stackoverflow post can be a great help.

How to read and understand the java stack trace?

Quote:

Generally the exact reason for the Exception is at the first line of your Stack Trace, and for more information about the cause of that exception, you need to gradually move down, and the root cause can often be found somewhere near the bottom of the stack trace.

I generally read the first line of the stack trace to determine what is happening, for your cause would be the OOM error, then I move to the last line and read from bottom up to see which object or area of code that could have caused the fault.

Community
  • 1
  • 1
Samuel Toh
  • 18,006
  • 3
  • 24
  • 39
0

In your startup script of the application, memory parameters for initial heap size allocated to your application, and the maximum heap size for the same

Please refer this for details. A startup command for the purpose can begin with something like

java -Xmx12288m <(followed by other necessary parameters)>

A sample command is given below for your reference

java -Xms1024m -Xmx12288m -XX:MaxPermSize=256m -Dlaser.home=$LASER_HOME -Djob=$job -Djava.library.path=$HADOOP_NATIVE -classpath "$CLASSPATH" $job_runner insights-workflow.xml $job run.date=$runDate env.type=$env
Community
  • 1
  • 1
Amal Gupta
  • 452
  • 4
  • 13
0

I faced a similar issue for my application, but it was related to spring. In my code, somehow an autowired dependency class got marked as abstract and I started getting this issue on server startup.

After almost a day of research we were able to identify the issue and fix it.

Rajat Dhain
  • 1