我们看到在我们的记录此警告消息
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=global,dc=com'
看来只要用户登录到我们的应用程序。
按照这个SO后 ，就可以通过设置来解决， Context.REFERRAL来follow 。 但它增加了搜索时间从1秒到4秒。
事实上，你可以参考这个SO后 ，它说，使用follow减慢搜索。
所以我的问题是，什么是摆脱我们将这一情况记录异常，而不会影响性能的最佳方式？
另一种可能工作可能的解决方案是改变的端口号（假设这是一个GC服务器）：
如果你正在使用的端口389将其更改为3268
如果你正在使用的端口636将其更改为3269
这可能工作，因为（我引述）：
在GC（全局编录）服务器返回389请示指的是更大的AD“森林”，但就像一个普通的LDAP服务器上的3268（3269和用于LDAPS）
它为我工作。
我发现，在Shibboleth的用户列表中该解决方案，由保罗·卡斯基（所有的功劳给他）回答。
您可以检查此链路上的对话：
https://lists.internet2.edu/sympa/arc/shibboleth-users/2008-06/msg00039.html
好。 你将看到这个异常，当你搜索返回转诊和你设置忽略转诊。
[推荐：当您在广告搜索，如果AD认为有在另一个地方提供更多的信息，它返回一个引用[地方与你的搜索结果一起找到更多信息。]
你可以通过设置避免此异常Context.REFERRAL来follow 。 然后，它会在转诊也搜索[这就是为什么它需要更多的时间才能返回结果。
但在我的案件转介是无效的，并返回一个另外的异常。
我通过改变基本DN（搜索库）更具体的解决了这个问题。 对于防爆： “OU =用户，DC = MYDOMAIN，DC = COM”。 现在，我没有看到这个例外，因为它不返回任何引用。
