1

次の例外がスローされる原因となっているCASの問題を追跡しようとしています。

javax.naming.TimeLimitExceededException: [LDAP: error code 3 - Timelimit Exceeded]; remaining name ''
        at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3097)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2987)
        at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2794)
        at com.sun.jndi.ldap.LdapNamingEnumeration.getNextBatch(LdapNamingEnumeration.java:129)
        at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:198)
        at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:171)
        at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:295)
        at org.springframework.ldap.core.LdapTemplate.search(LdapTemplate.java:361)...

エラーは事実上即座に返されます。クライアント側のタイムアウトは10秒に設定されていますが、com.sun.jndi.ldapコードを調べると、ドメインコントローラーがステータス3の応答を返しているように見えるため、これは発生していません。制限時間を超えました。

Active Directoryグローバルカタログにアクセスしており、フィルターとベースはかなり広いです：base =''、filter =（proxyAddresses = *：someone@somewhere.com）ただし、クエリは成功することがありますが、すぐにステータスコード3が返されます。 。

誰かがこの種の行動を引き起こしている可能性があることを知っていますか？それとも、正確に何が起こっているのかを判断する方法はありますか？

4

1 に答える 1

1

検索フィルターが広すぎたことがわかりました。

ご覧のとおり、フィルターでワイルドカードを使用しており、クエリに2秒弱かかりました。

ただし、2秒はActive Directoryで構成された制限時間よりもはるかに短いため、エラーがすぐに発生した理由を理解できませんでした（失敗したときに2秒もかかりませんでした）。

ADは、同じアカウントからの複数のリクエストにかかる時間を蓄積していたに違いないと思います。ある時点で、制限時間を超えたエラーが返され始めました。

これを解決するために、ワイルドカードが含まれないように検索フィルターを変更しました。その後、検索はほぼ瞬時に実行され、制限時間を超えることはなくなります。

于 2013-05-13T14:28:29.533 に答える