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." <smithh032...@gmail.com> Date: To: Tomcat Users List <users@tomcat.apache.org> 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 issues. >> >> 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: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
