Potential performance impact of embedded Crowd directory ordering

We have noticed the performance impact described below with our internal Stash instance and report this for the benefit of the wider Stash community.

We noticed that the directory setup on a Stash instance could be improved by reordering the directories.

We observed high rates of requests from the Stash instance to a Crowd instance for authentication of Bamboo build users in the internal Stash directory. 

As an interim workaround we reordered the directories to avoid trying to authenticate the build user accounts against Crowd.

The problem

Say you've got a number of directories defined in Stash in the following order:

• Remote Crowd directory
• Internal directory

If a user from the internal directory tries to authenticate, Crowd will currently:

• attempt to authenticate against the first directory, resulting in a remote call to Crowd. Crowd won't find the user and returns a 400.
• attempt to authenticate against the second directory, where the user is found and authentication succeeds.

This means that every authentication pays the cost of a call to the remote Crowd server. 

This scenario is not unrealistic. In many cases the Crowd/LDAP directory should be the primary directory and a second internal directory may exist for non-standard users, typically for automated systems such as Bamboo and FishEye.