[GitHub] [tomcat] rmannibucau opened a new pull request #398: Ensure StandardContext#postWorkDirectory is protected

2020-12-27 Thread GitBox


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?

2020-12-27 Thread Romain Manni-Bucau
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?

2020-12-27 Thread Jean-Baptiste Onofre
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

2020-12-27 Thread bugzilla
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

2020-12-27 Thread bugzilla
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