[GitHub] [tomcat] rmannibucau opened a new pull request #398: Ensure StandardContext#postWorkDirectory is protected
rmannibucau opened a new pull request #398: URL: https://github.com/apache/tomcat/pull/398 Goal is to enable to run tomcat without any temporary files. For programmatic cases it is often possible and desired (note it is ok to skip jakarta.servlet.context.tempdir for such case). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat 10 startup time and JMX as an opt in fature?
Hi everyone, wonder if there is some work planned in tomcat 10 to 1. makes it start faster and 2. make jmx optional. I did some tests and locally a tomcat start is about 400ms. I was surprised to see that Registry.disableRegistry() was taking already 65ms whereas it should be almost nothing so refactored the code, added a RegistryFactory and really noop impl (not even a mock) and went down to 1ms, way better right? except the remaining 64ms went to the next line (new StandardHost()). After some investigation time is mainly classloading time (in all senses). So I wonder if it wouldnt make sense to optimize tomcat startup time + finally make JMX optional since it is no more used by users in most cases - gues we must keep it as an optional plugin since it is used "historically". The proposal would be to: 1. reduce classloading tree as much as possible for default case - here having jmx optional will help a lot 2. probably generate resource bundle as .java at build time to avoid all the classloading resource bundle implies (it is like 74 loadClass + as much getResource for a simple startup and all loadclass are misses) 2.bis. probably add a mode where StringManager uses the default bundle without passing through the resource bundle layer 3. cut dead code when we know it is inactive (typically the case for jmx) 4. open point: bypassing Context: in "main" mode (as the code shared after), you just want to bind some logic in a servlet/filter/valve, you don't always care about handling contexts (or a single one) so wonder if we shouldnt evaluate the fact to add the user logic in a valve for this kind of bench and maybe document this case (spring boot could inherit from it since it almost never use anything else that default spring servlet and binds everything in it). Here is the kind of case I'd like to see insanely fast (<100ms - and it is possible regarding what it does): public class Main { public static void main(String[] args) throws LifecycleException, InterruptedException { final long start = System.nanoTime(); Registry.disableRegistry(); final long startDisableRegistry = System.nanoTime(); final Host host = new StandardHost(); host.setName("localhost"); final long startHost = System.nanoTime(); final Engine engine = new StandardEngine(); engine.setName("Tomcat"); engine.setDefaultHost("localhost"); engine.setRealm(new NullRealm()); engine.addChild(host); final long startEngine = System.nanoTime(); final var protocolHandler = new Http11Nio2Protocol(); protocolHandler.setPort(8080); final long startHttp11Nio2Protocol = System.nanoTime(); final Service service = new StandardService(); service.setName("Tomcat"); service.setContainer(engine); service.addConnector(new Connector(protocolHandler)); final long startService = System.nanoTime(); final StandardServer server = new StandardServer(); server.setPort(-1); server.addService(service); final long startServer = System.nanoTime(); final StandardContext context = new StandardContext(); context.setUseNaming(false); context.setClearReferencesStopThreads(false); context.setClearReferencesStopTimerThreads(false); context.setClearReferencesHttpClientKeepAliveThread(false); context.setClearReferencesRmiTargets(false); context.setClearReferencesThreadLocals(false); context.setClearReferencesObjectStreamClassCaches(false); context.setWorkDir(System.getProperty("java.io.tmpdir")); context.setName(""); context.setPath(""); context.setDocBase(null); context.addLifecycleListener(event -> { if (event.getType().equals(Lifecycle.CONFIGURE_START_EVENT)) { context.setConfigured(true); if (context.getLoginConfig() == null) { context.setLoginConfig(new LoginConfig("NONE", null, null, null)); context.getPipeline().addValve(new NonLoginAuthenticator()); } } }); context.addServletContainerInitializer((classes, ctx) -> { ctx.addServlet("default", new DefaultServlet()) .addMapping("/"); }, Set.of()); final long startContext = System.nanoTime(); host.addChild(context); server.init(); final long inited = System.nanoTime(); server.start(); final long started = System.nanoTime(); // new CountDownLatch(1).await(); final var contextClassLoader = Thread.currentThread().getContextClassLoader(); server.stop(); server.destroy(); final long stopped = System.nanoTime(); System.out.println(TimeUnit.NANOSECONDS.toMillis(started - start) + "ms"); System.out.println(TimeUnit.NANOSECONDS.toMillis(stopped - started) + "ms");
Re: Tomcat 10 startup time and JMX as an opt in fature?
Hi, If it’s optional but still enabled, I think it’s a good idea to speedup bootstrapping. Just my $0.01 ;) Regards JB > Le 27 déc. 2020 à 16:15, Romain Manni-Bucau a écrit : > > Hi everyone, > > wonder if there is some work planned in tomcat 10 to 1. makes it start > faster and 2. make jmx optional. > > I did some tests and locally a tomcat start is about 400ms. > I was surprised to see that Registry.disableRegistry() was taking already > 65ms whereas it should be almost nothing so refactored the code, added a > RegistryFactory and really noop impl (not even a mock) and went down to > 1ms, way better right? except the remaining 64ms went to the next line (new > StandardHost()). After some investigation time is mainly classloading time > (in all senses). > > So I wonder if it wouldnt make sense to optimize tomcat startup time + > finally make JMX optional since it is no more used by users in most cases - > gues we must keep it as an optional plugin since it is used "historically". > > The proposal would be to: > > 1. reduce classloading tree as much as possible for default case - here > having jmx optional will help a lot > 2. probably generate resource bundle as .java at build time to avoid all > the classloading resource bundle implies (it is like 74 loadClass + as much > getResource for a simple startup and all loadclass are misses) > 2.bis. probably add a mode where StringManager uses the default bundle > without passing through the resource bundle layer > 3. cut dead code when we know it is inactive (typically the case for jmx) > 4. open point: bypassing Context: in "main" mode (as the code shared > after), you just want to bind some logic in a servlet/filter/valve, you > don't always care about handling contexts (or a single one) so wonder if we > shouldnt evaluate the fact to add the user logic in a valve for this kind > of bench and maybe document this case (spring boot could inherit from it > since it almost never use anything else that default spring servlet and > binds everything in it). > > Here is the kind of case I'd like to see insanely fast (<100ms - and it is > possible regarding what it does): > > public class Main { >public static void main(String[] args) throws LifecycleException, > InterruptedException { >final long start = System.nanoTime(); >Registry.disableRegistry(); >final long startDisableRegistry = System.nanoTime(); > >final Host host = new StandardHost(); >host.setName("localhost"); >final long startHost = System.nanoTime(); > >final Engine engine = new StandardEngine(); >engine.setName("Tomcat"); >engine.setDefaultHost("localhost"); >engine.setRealm(new NullRealm()); >engine.addChild(host); >final long startEngine = System.nanoTime(); > >final var protocolHandler = new Http11Nio2Protocol(); >protocolHandler.setPort(8080); >final long startHttp11Nio2Protocol = System.nanoTime(); > >final Service service = new StandardService(); >service.setName("Tomcat"); >service.setContainer(engine); >service.addConnector(new Connector(protocolHandler)); >final long startService = System.nanoTime(); > >final StandardServer server = new StandardServer(); >server.setPort(-1); >server.addService(service); >final long startServer = System.nanoTime(); > >final StandardContext context = new StandardContext(); >context.setUseNaming(false); >context.setClearReferencesStopThreads(false); >context.setClearReferencesStopTimerThreads(false); >context.setClearReferencesHttpClientKeepAliveThread(false); >context.setClearReferencesRmiTargets(false); >context.setClearReferencesThreadLocals(false); >context.setClearReferencesObjectStreamClassCaches(false); >context.setWorkDir(System.getProperty("java.io.tmpdir")); >context.setName(""); >context.setPath(""); >context.setDocBase(null); >context.addLifecycleListener(event -> { >if (event.getType().equals(Lifecycle.CONFIGURE_START_EVENT)) { >context.setConfigured(true); >if (context.getLoginConfig() == null) { >context.setLoginConfig(new LoginConfig("NONE", null, > null, null)); >context.getPipeline().addValve(new > NonLoginAuthenticator()); >} >} >}); >context.addServletContainerInitializer((classes, ctx) -> { >ctx.addServlet("default", new DefaultServlet()) >.addMapping("/"); >}, Set.of()); >final long startContext = System.nanoTime(); > >host.addChild(context); > >server.init(); >final long inited = System.nanoTime(); >server.start(); >final long started = System.nanoTime(); >// new CountDownLatch(1).await(); > >fi
[Bug 65033] New: Tomcat 8.5.60/61 User authentication with JNDIRealm failure
https://bz.apache.org/bugzilla/show_bug.cgi?id=65033 Bug ID: 65033 Summary: Tomcat 8.5.60/61 User authentication with JNDIRealm failure Product: Tomcat 8 Version: 8.5.60 Hardware: PC OS: Linux Status: NEW Severity: critical Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: rsnraju...@gmail.com Target Milestone: Tomcat version : Tomcat 8.5.60/61 below is applied configuration in our environment 1. Realm Configuration: --- ldap://XX.XX.XX.XX:389"; useStartTls="true" userPattern="uid={0},ou=people,ou=accounts,dc=netact,dc=net"/> 2. LDAP and tomcat_users.xml has user credentials(ldapuser/ldapuser). with the above configuration , Tomcat will try to authenticate the user against JNDIRealm(LDAP) first and later the UserdatabaseRealm(tomcat_users.xml). User(ldapuser) tries to authenticates when ldap is down. User(ldapuser) authentication successful for the 1st time. User(ldapuser) tries to authenticates again when ldap is down. User(ldapuser) authentication is not successful for the 2nd time. looks like there is an hung when JNDIRealm.authenticate being invoked from CombinedRealm.authenticate. JNDIRealm.authenticate not returning any response as per the generated logs. Principal authenticate(String username, String credentials) Logs: - Dec 27, 2020 10:59:42 PM org.apache.catalina.authenticator.AuthenticatorBase invoke FINE: Calling authenticate() Dec 27, 2020 10:59:42 PM org.apache.catalina.authenticator.FormAuthenticator doAuthenticate FINE: Authenticating username 'ldapuser1' Dec 27, 2020 10:59:42 PM com.nokia.oss.esymac.realm.CustomLockOutRealm authenticate INFO: authenticate usernameldapuser1 , credentials ldapuser1 Dec 27, 2020 10:59:42 PM com.nokia.oss.esymac.realm.CustomLockOutRealm authenticate INFO: before authenticate.. Dec 27, 2020 10:59:42 PM com.nokia.oss.esymac.realm.DefaultLockOutRealm authenticate INFO: DefaultLockouRealm start authenticate..ldapuser1 Dec 27, 2020 10:59:42 PM com.nokia.oss.esymac.realm.DefaultLockOutRealm authenticate INFO: DefaultLockouRealm stabefore authenticate..ldapuser1 Dec 27, 2020 10:59:42 PM org.apache.catalina.realm.CombinedRealm authenticate FINE: Attempting to authenticate user [ldapuser1] with realm [org.apache.catalina.realm.CombinedRealm] Dec 27, 2020 10:59:42 PM org.apache.catalina.realm.CombinedRealm authenticate FINE: Attempting to authenticate user [ldapuser1] with realm [org.apache.catalina.realm.JNDIRealm] Note : With Tomcat 8.5.59 this issue not observed. Please let us know if any other information needed. -- 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 65033] Tomcat 8.5.60/61 User authentication with JNDIRealm failure
https://bz.apache.org/bugzilla/show_bug.cgi?id=65033 Satya changed: What|Removed |Added CC||rsnraju...@gmail.com -- 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