[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 --- Comment #8 from Peter --- Thanks. I tested commit 30e89f9efb571a19d2d3239db7b5e0c17f86b812 (tomcat85 repo) which works like the second possibly hacky patch. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Mark Thomas --- Thanks for the work on this and especially for the patches. There is already retry code in the public authenticate() method. Fundamentally this hits up against a problem that the previous code was trying to deal with - how do you tell if a NamingException is something that requires fail over? The short answer is you can't always tell and the previous code was not failing over unless there was a clear indication (via the Exception type) that such a fail over was required. I have changed the logic so it always attempts to fail over. This won't be perfect either but I'd rather it always attempted to fail over and therefore always worked when it could and we get a few extra error messages than it didn't try to fail over and therefore failed when a fail over could have resulted in correct operation. I've also included the readTimeout improvements. Fixed in: - trunk for 9.0.0.M25 onwards - 8.5.x for 8.5.19 onwards - 8.0.x for 8.0.46 onwards - 7.0.x for 7.0.80 onwards -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 --- Comment #6 from Peter --- Created attachment 35151 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35151&action=edit second possibly hacky patch, includes Felix's patch Here's another possibly hacky patch. This one looks less hacky, but it only covers the one place where the exception I observed happens. I chose that place because it is the first call of a protected method in the stack; the others before are public. And I don't know if it could loop forever, or pointlessly retry when there is another kind of exception which is also a NamingException (this one is a read timeout... I don't know what else there is). With this patch, the problem is fixed in my testing... a failed server that was already in a previous context will cause only a delay about 0.5s plus the readTimeout. And both servers down will result in the "HTTP Status 401 – Unauthorized" error and delay will also be about 0.5s plus the readTimeout. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 --- Comment #5 from Peter --- The code just closes the context and returns null, and does not retry, so I guess that explains why it fails. line 1326 JNDIRealm.java } catch (NamingException e) { // Log the problem for posterity containerLog.error(sm.getString("jndiRealm.exception"), e); // Close the connection so that it gets reopened next time if (context != null) close(context); // Return "not authenticated" for this request if (containerLog.isDebugEnabled()) containerLog.debug("Returning null principal."); return null; } SEVERE: org.apache.catalina.realm.JNDIRealm: Exception performing authentication javax.naming.NamingException: LDAP response read timed out, timeout used:500ms.; remaining name 'uid=urban1,ou=People,dc=bc,dc=local' at com.sun.jndi.ldap.Connection.readReply(Connection.java:490) at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2788) at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2696) at com.sun.jndi.ldap.LdapCtx.ensureOpen(LdapCtx.java:2670) at com.sun.jndi.ldap.LdapCtx.doSearch(LdapCtx.java:1941) at com.sun.jndi.ldap.LdapCtx.doSearchOnce(LdapCtx.java:1933) at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1325) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:235) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:141) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:129) at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) at org.apache.catalina.realm.JNDIRealm.getUserByPattern(JNDIRealm.java:1558) at org.apache.catalina.realm.JNDIRealm.getUserByPattern(JNDIRealm.java:1624) at org.apache.catalina.realm.JNDIRealm.getUser(JNDIRealm.java:1499) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1377) at org.apache.catalina.realm.JNDIRealm.authenticate(JNDIRealm.java:1295) at org.apache.catalina.authenticator.BasicAuthenticator.doAuthenticate(BasicAuthenticator.java:73) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:560) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 Peter changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #4 from Peter --- Using Felix's patch, letting the tomcat warm up with some ok requests and both auth servers online, then taking the first down, then doing a request (to our regular app, or the dummy), it takes 6s to fail and says: HTTP Status 401 – Unauthorizedh1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} h2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} h3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} body {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} b {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} p {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;} a {color:black;} a.name {color:black;} .line {height:1px;background-color:#525D76;border:none;}HTTP Status 401 – UnauthorizedType Status ReportDescription The request has not been applied because it lacks valid authentication credentials for the target resource.Apache Tomcat/8.5.16 And then subsequent requests work fine. (but the dummy always says the above, so I guess you can't test that) Doing the failure the other way around works the same. If I set the timeout to 500 in the server.xml, it takes 1s instead. So the timeout works great, but it doesn't seem to fall back to the alternate/connection URL. So I think the patch is good, but incomplete. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 Mark Thomas changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Mark Thomas --- Please test Felix's proposed patch and report back. Note: if it works, the documentation will need to be updated as well. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 Felix Schumacher changed: What|Removed |Added Attachment #35146|0 |1 is obsolete|| --- Comment #2 from Felix Schumacher --- Created attachment 35148 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35148&action=edit Add an option to set a read timeout to ldap connections used by JNDI Realm Java LDAP API seems to have an option for read timeouts. This should shorten the timeouts that you see when the firewall looses the connection state and starts dropping the packets. I haven't tested the patch yet and I think it would be even better to have an timeout on connections that aren't used for a long time, too. If the LDAP API has no such timeout, we could emulate it by keeping a timestamp up to date in close and open calls. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 61313] JNDIRealm LDAP server failover to alternateURL takes very long 15m32s
https://bz.apache.org/bugzilla/show_bug.cgi?id=61313 --- Comment #1 from Peter --- Created attachment 35147 --> https://bz.apache.org/bugzilla/attachment.cgi?id=35147&action=edit an example webapp that can be used for testing If it says "The origin server did not find a current representation for the target resource or is not willing to disclose that one exists." that's fine... it just means the user doesn't exist or something, but it got to the LDAP server. I have verified it is fast with my patch and slow without it. If it says "The request has not been applied because it lacks valid authentication credentials for the target resource." it means it can't contact any LDAP server, which is probably fine as long as it's fast. I verified that it's fast with my patch and slow without it. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org