Picasso no longer sends request to remote server after random event....

[Qubitium]

We are using v2.4 with a CustomOkHttpDownloader which only adds 2 http headers to the request.

The requests are performed over spdy 3.1. The issue that after about 5-10 minutes of heavy async/loading of pngs into ImageViews in listViews, picasso no longer sends spdy calls to our backend server and requires us to force kill the app to have picasso resume proper loading of remote images. We are using the default pool config but a custom pool value also doesn't help.

Strange thing is we use okhttp/spicemanager to issue spdy 3.1 calls, for non-image/json requests, to the same server and have no issues regardless how long the app has been active. Only picasso has the problem. Let us know if there is anything else we can provide to help track down this problem.

When the error happens, we get tons of the following log entries:

11-19 16:28:27.701 28781-31749/com.lbxtech.myapp W/MessageQueue﹕ Handler (com.squareup.picasso.l) {65274850} sending message to a Handler on a dead thread
java.lang.RuntimeException: Handler (com.squareup.picasso.l) {65274850} sending message to a Handler on a dead thread
at android.os.MessageQueue.enqueueMessage(MessageQueue.java:320)
at android.os.Handler.enqueueMessage(Handler.java:626)
at android.os.Handler.sendMessageAtTime(Handler.java:595)
at android.os.Handler.sendMessageDelayed(Handler.java:566)
at com.squareup.picasso.k.b(Dispatcher.java:156)
at com.squareup.picasso.d.run(BitmapHunter.java:123)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:422)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:811)
at com.squareup.picasso.au.run(Utils.java:408)

[dnkoutso]

Wonder if the Dispatcher thread crashed and the main thread still works.

It seems like you are obfuscating your code. Can you run without it and perhaps try to reproduce and see how the Dispatcher thread might die?

[dnkoutso]

Or perhaps one of the worker threads crashed unexpectedly.

[Qubitium]

Today, we experimented with commenting out Picasso.Destroy() calls within our Activity OnDestroy() methods...and this small change appears to have resolved our issue. Strange.

[JakeWharton]

What is Picasso.Destroy? Do you mean shutdown? Does that mean you are
creating a Picasso instance per activity?
On Nov 20, 2014 11:09 PM, "diegomontoya" notifications@github.com wrote:

Today, we experimented with commenting out Picasso.Destroy() calls within
our Activity OnDestroy() methods...and this small change appears to have
resolved our issue. Strange.

—
Reply to this email directly or view it on GitHub
#760 (comment).

[Qubitium]

Typo: We called Picasso.shutdown()...not destory()..

Yes, we are creating a picasso instance per activity and in our old code, calling shutdown() within activity.OnDestroy()

[JakeWharton]

Why do you that instead of using a single instance? Everything is better with a single instance. With multiple instances you are in danger of easily gobbling up all of the available heap space very quickly.

[Qubitium]

Thanks for the info. Looks like we are using using picasso in an unsafe/unsupported way. We have now moved picasso to a single app scope instance per recommendation.

[JakeWharton]

Calling .shutdown() should fix the unsafe usage, but using a single instance across your entire app is highly, highly recommended because there are so many advantages. I suspect the exception is just a function of some other failure that occurred from having so many instances of Picasso which eats threads and heap like no other.