tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <>
Subject Re: Help in diagnosing server unresponsiveness
Date Fri, 01 Feb 2013 23:27:45 GMT
>> If you want to improve performance even more, ditch EJB altogether.
>> Moving from APR to NIO may be a good move, but it really depends upon
>> your requirements. For instance, APR provides superior SSL performance
>> but if you don't need it, NIO will probably give you better results.

Understood, thanks Chris. For now, only office personnel is accessing
the web app behind a firewall, and others (including myself) access
via laptop and mobile devices outside of the office via HTTP, so NIO
is sufficient for now, until I'm ready to go HTTPS/SSL via APR.

>> That depends upon what you want to accomplish. You can get messages
>> about JDBC resource management problems without writing any
>> interceptors at all.

Okay, well,  I'm using JPA to access JTA managed datasource (Apache
Derby), and I really don't think I have any JDBC resource management

>> That depends upon what you mean by "clustering". If you want to serve
>> more clients (or have fault-tolerance), then "clustering" is a good
>> idea. "Clustering" means different things to different people. If you
>> just want to scale horizontally (more app servers) and use simple
>> load-balancing, that can be considered a cluster.

For now, I want a cluster of at least 2 or 3 tomcat servers for
fault-tolerance and load balancing.

> When I mention thread programming, I mean WebApps that start (Java) threads
> to do background work, like import data, send automatica notifications, and
> so on. I know it is a (almost) bad practice to have web apps creating
> threads, but this is so common in real world enterprise apps!

Yes, I read that it is not good for web apps to start (Java) threads
to do background work, and per that advise, I have avoided that for
now. so far, I have used @Asynchronous and @Schedule, very minimally.

>> In the Java world, most people would only call it a consider it a
>> "cluster" if the app servers actually know about each other -- for
>> instance, if you are using session replication. IMO session
>> replication is a dog, and there are better ways to achieve similar
>> goals that yield much higher performance.

Chris, I'm glad you mentioned, "IMO session replication is a dog",
because honestly, I would love to avoid some of the pre-work required
to prepare my app for session replication. I'm definitely interested
in the 'better ways to achieve similar goals. I would love to have 2
or 3 instances of my web app accessing one database (Derby, at the
present), and all 2 or 3 instances actually knowing about each other.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message