Android capture start to sync data, but waitting for long time, many authentication info

after login, the screen stop at syncing data …, no over.
and found many duplicated info in catalina.out file as:

  • INFO 2020-05-11T08:13:27,965 Login attempt: xxxxxx ( [http-nio-10010-exec-6])
  • INFO 2020-05-11T08:13:28,106 Login attempt: xxxx ( [http-nio-10010-exec-4])
  • WARN 2020-05-11T08:13:28,119 Authentication event AuthenticationSuccessEvent: xxxx; ip: ( [http-nio-10010-exec-6])
  • WARN 2020-05-11T08:13:28,255 Authentication event AuthenticationSuccessEvent: xxxxx; ip: ( [http-nio-10010-exec-4])
  • INFO 2020-05-11T08:13:28,290 Login attempt: xxxx( [http-nio-10010-exec-14])
  • INFO 2020-05-11T08:13:28,431 Login attempt: xxx( [http-nio-10010-exec-15])
  • WARN 2020-05-11T08:13:28,441 Authentication event AuthenticationSuccessEvent: xxxx; ip: ( [http-nio-10010-exec-14])

Hello @linxd,

One of the main misconfigurations with the Android application is that the user has access to many Organisation Units; therefore when logging in there is a huge amount of data to be transferred to the device and this, with the fact that the first writing to the local database is somehow slow usually produces the mentioned issue.

Could you make sure that the user has access only to the specific OU where they are supposed to capture data and let us know if you still have the issue?


my user only assinged to one org with 700 suborg. if only few , the issue not exist.

Hey @linxd. Does that user needs to enter information in those 700 suborg units? Cause we usually recommend having the user only assigned to the OU where they will be capturing data. This can be different from the search so they will be able to find patients in other OU but will not download them on the initial sync.

how to manage user for about more than 100000 hospital/clinic? and there more than 1000 clinics for every county .
is dhis2 not suitable for thsi scenario?

Hi @linxd.

Is this user entering data in those 100000 hospitals? Or in those all clinics? The Android App is conceived to work offline and therefore downloading all the resources it might need while being offline; this is the reason when a user is assigned to X OUs all those OUs with the information will be downloaded.

We have seen that there is usually a misconception with that and only one user is created and shared among all those clinics. The best approach will be that there are as many users as needed (one per clinic if that is the real case, although sometimes it might be a user traveling to several clinics so this is not a strict rule) and assigning to each of those users the minimum OUs, Programs and DataSets to work.

Does this make sense? If you need a further explanation let me know and will try to describe better.



The dhis2 can manage more than 100000 users ? and the self register can’t setting org. how to create so many user for so many orgs?

I don’t think there should be a problem in terms of user but maybe someone from @dhis2-backend can give you better info.

Regarding the amount users you will probably need to import them from a CSV or have a script that creates them. Do you have all the OU already created? How did you do it? Because in order to import the users and assign the rights properly you will need the OU UID.

Just to be clear, having 100000 users might not be the best approach as it might include too much additional workload. Maybe you could try to balance the amount of users / OU. But definitely a user for 100000 OUs is going to make the Android app nearly impossible to use.


Hi @linxd,

Nice to hear from you.

Maybe others with more experience than I can answer this better – but I think that self registration is most useful for an installation where all the data is available to the public. Users can self-register at the root organization and then have access to all the data. Typically the self-registered users can see all the data in the system but not change it. I agree with you that self-registration is not very good if the user will be restricted to an organisation unit, because the user cannot select which organisation unit.

For a country with many users and many organisation units, I think the most common way is to create an organisation unit hierarchy that follows an administrative hierarchy. Hospitals are grouped by the lowest level of administrative group. The lowest level groups are grouped into administrative groups at the next higher level. And so on. If there are multiple users within a hospital, you can create one or more user administrators for that hospital who are responsible for the users in that hospital. Then you create one or more users at the lowest administrative group who are responsible for creating the user administrators in each hospital. Then at the next higher administrative group, you create users who can create the users in the lowest administrative group. And so on. So the user administration is distributed according to an administrative hierarchy, which the organisation unit hierarchy is designed to follow. This may be the easiest way to manage a very large number of DHIS2 users.

In the PEPFAR instance, there are over 110,000 organisation units, and this works fine in DHIS2. There are about 23,000 users. I don’t see any reason why DHIS2 should not support 100,000 users, though I don’t know if we have any current instances with that many. Maybe someone else knows.

I think the best design for DHIS2 is where each organisation unit has a limited number of direct children. For example, in the PEPFAR instance, we had the global level as the root, and countries as the next level down. The system worked better when we introduced an organisation unit level “continent” between global and country, so each continent has a limited number of children countries, instead of all the countries being under the single global organisation unit. This means when a part of the organisation unit hierarchy is loading, there are fewer organisation units to load at each level, so it performs better.

Likewise, the best design is where each user is assigned to as few organisation units as possible. Ideally each user would be assigned to only one organisation unit, which includes the part of the subtree where the user is authorized to work. But a user can be assigned to a small number of organisation units as well. If this number gets too large it can be a performance problem, as @jaime.bosque says.

If you have a user that is assigned to an organisation unit with many sub-orgs, the user does not have to be assigned to all the sub-orgs also, only to the parent organisation unit.

I hope this helps. Let us know if you have other questions, or maybe we didn’t understand well the questions that you had.

Jim Grace

1 Like

Thanks. I will write a page to regiester user to choosed org.

I have request the user to self register,
and after login, the event can’t sync success,
I must change the sync config to by org and prog, and sync manually, then ok.

It’s unreasonable. OK??

Hi @linxd .

I didn’t fully understand your message. What do you mean that you have to change the sync config? Can you explain a bit with more details?


register first, then login to app first time ,(usually need cost more time depend on the events owned by the user), coming the first page, but there is no events for all programs.

then, I go into configure, change the sync policy to sync by org and program or sync by org, and sync manually, return to main page,there is the events.

may logout and login again, there will be seen the events.

HI @linxd. Is this a testing server? Could you share the credentials with me (via private email) so I can check a bit better?

2 posts were merged into an existing topic: Android capture app 2.5 still cost too long time to login or sync data?