tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dragon101.1" <>
Subject Re: Help in diagnosing server unresponsiveness
Date Sun, 03 Feb 2013 21:38:14 GMT

hello my name is tommy gunzelman i signed up because sending a message i noticed tomcat sent
i was curious however thing are more than meets the eye is im informing you please check if
im receiving any my than just mail if so its without my consent and i need to be informed
please call me directly 505-554-7878 thank you

From my Android phone on T-Mobile. The first nationwide 4G network.

-------- Original message --------
From: "Howard W. Smith, Jr." <> 
To: Tomcat Users List <> 
Subject: Re: Help in diagnosing server unresponsiveness 
>> 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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message