The kingdom causes many ANR

Question

In my own testing, I did not encounter this problem, but as soon as my application was published, ANR began to flood. My application currently has 22 ANRs, some of which are reported as 100 times. All the traces seem to be related to trying to create a new instance of Realm in the user interface thread.

"main" prio=5 tid=1 MONITOR | group="main" sCount=1 dsCount=0 obj=0x4183ede0 self=0x417548b8 | sysTid=19680 nice=0 sched=0/0 cgrp=apps handle=1073975684 | state=S schedstat=( 2816413167 710323137 3658 ) utm=215 stm=66 core=1 at io.realm.Realm.createAndValidate(Realm.java:~495) - waiting to lock <0x41df9c98> held by tid=12 (IntentService[UASyncService]) at io.realm.Realm.create(Realm.java:486) at io.realm.Realm.getInstance(Realm.java:404) at io.realm.Realm.getInstance(Realm.java:366) at io.realm.Realm.getInstance(Realm.java:347) 

I believe the root of this problem, as the bader said, is that I have an open Realm transaction in the workflow that blocks my attempts to get a Realm instance in the UI thread that calls ANR.

I will update later after I have a solution.

* Edit: updated information has been added.

Answer 1

The kingdom no longer has this problem.

For reference, my solution at that time was:

Thanks to beeender for pointing me in the right direction and linking this PR https://github.com/realm/realm-java/pull/1297

Question

When there is a transaction with a pending Realm transaction, any call to Realm.getInstance in another thread is blocked until the pending transaction is completed or canceled.

In my case, I have an IntentService that populates my Realm with existing user data, while I try to display any current data by querying Realm in the user interface thread. Although the requests are simple and do not cause any problems normally, if there is a pending transaction in the IntentService, the call to Realm.getInstance will be blocked, blocking the UI thread that potentially calls ANR.

My first attempt at a solution was to pull out a branch of the beeender PR team and create a jar. I believe this fix helped me take another step, allowing me to create an instance of Realm without blocking, but the UI thread was still blocked by small transactions that I tried to execute in the UI thread.

Decision

The implemented solution includes several stages:

• Create repeating objects for all my models. Duplicates do not distribute RealmObject (since RealmObjects cannot be used on streams.)
• Move all calls in Realm to background threads. I basically wrapped my queries in AsyncTasks and added listeners that return a version of the model other than RealmObject.
• Make smaller transactions, not less large transactions. Where previously I started and made transactions on both sides of the cycle that created many new RealmObjects, now I start and commit the transaction for each object. The goal of this is to reduce the total continuous time during which Realm can be in an open transaction state, so my requests providing data for the user interface can complete without having to wait.

Conclusion

I initially did not dare to use Realm due to the fact that it is still in beta, as well as a warning that RealmObjects cannot be used in streams. After some tests, I was sure that I could perform simple queries on the user interface thread without problems (still with guilt in my gut).

A common kingdom is a great project to follow, but I feel that it is not ready for large-scale commercial projects. Using Realm in this project may have saved time, but it cost many dissatisfied customers and it is difficult to diagnose the problem.

* Edit: Clarified question.

Answer 2

An example implementation in Realm shows them using AsyncTask to read and write them.

Any expensive I / O, whether from a network, database, or large file, should usually be stored in the main thread, as this will lead to a sluggish interface. Without seeing my code, I would suggest that if you get ANR, you are probably doing something too complex for the main thread.