Document HttpLoggingInterceptor buffers content

We should document (further) that the logging interceptor is not general purpose and fully buffers bodies.

Additionally, consider aggregating a single string for a request and a single string for each response to call the logger with to prevent interleaving on the console/logcat/wherever.

old issue below:

---

Hi, I’m working on an android app which downloads books. some of the books are really large and HttpLoggingInterceptor tries to log them and therefore I’m getting OutOfMemoryError which looks like this:

09-17 15:57:02.095 15408-15672/com.some.example E/AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
    Process: com.some.example, PID: 15408
    java.lang.OutOfMemoryError: Failed to allocate a 122708494 byte allocation with 16777216 free bytes and 93MB until OOM
        at java.lang.StringFactory.newStringFromBytes(StringFactory.java:79)
        at java.lang.StringFactory.newStringFromBytes(StringFactory.java:207)
        at okio.Buffer.readString(Buffer.java:631)
        at okio.Buffer.readString(Buffer.java:614)
        at okhttp3.logging.HttpLoggingInterceptor.intercept(HttpLoggingInterceptor.java:273)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:147)
        at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:121)
        at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:200)
        at okhttp3.RealCall$AsyncCall.execute(RealCall.java:147)
        at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
        at java.lang.Thread.run(Thread.java:818)

in production im not logging the body which fixes the error, but in development i want to be able to log it, how do you suggest me to tackle this issue? thanks.

[swankjesse]

Also – we don’t buffer the content ’cause we’re lazy and don’t know how to do streaming. We buffer it because we think that when a developer is viewing logs they don’t want the bodies of multiple responses to be interleaved. I know you don’t care about that, but that makes you special! And that’s why we have this interceptors API so you can do what you like.

And finally, it’s annoying to open source contributors when you threaten to take your business elsewhere. We’re not trying to build a library that meets everyone’s needs (because we think that would be big and complicated). Instead we’re trying to build a small but extensible library that meets most people’s needs. Whenever somebody says “add my feature or I’m leaving” it isn’t endearing.

[bpappin]

• yes used almost exclusivly in debugging, but should still never throw an OOM.
• buffering may, or may not be important to the user. Generally the dev just needs to see what is going on, but it is reasonable to truncate, if you must buffer, in order to prevent an OOM.
• How hard would it be to simply provide a non-buffering logger, or one that allowed you to specify what endpoints it used? I will contribute it myself, when I have some time, but someone managing the project would have to take ownership.
• threatening to take my business elsewhere is not what this has been about, and I think you know that. It is about being able to trust the libraries you depend on for your livelihood, not to surprise you with something like an OOM.
• I am flabbergasted that we are even having this discussion.