Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of edsonrichter@hotmail.com
 designates 65.55.111.91 as permitted sender)
Message-ID: <BLU0-SMTP935BFD7FA5AAA29D42B86ECF1C0@phx.gbl>
Date: Fri, 1 Feb 2013 17:32:13 -0200
From: Edson Richter <edsonrichter@hotmail.com>
Organization: Simkorp =?ISO-8859-1?Q?Inform=E1tica_Ltda?=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: Help in diagnosing server unresponsiveness
References: <CD31675F.34C73%zoran@sparecreative.com>
 <BLU0-SMTP151B7CA8D4280D2DDB02953CF1C0@phx.gbl>
 <BLU0-SMTP2470B39640025B1F6F4C101CF1C0@phx.gbl>
 <CAGV1rD+_0v_Vq4VimAVmSCyg6nWjKH39aUfFVym3Cx==8jbOWg@mail.gmail.com>
 <510C157C.2000100@christopherschultz.net>
In-Reply-To: <510C157C.2000100@christopherschultz.net>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Em 01/02/2013 17:20, Christopher Schultz escreveu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Howard,
>
> On 2/1/13 12:41 PM, Howard W. Smith, Jr. wrote:
>> my app is running fine, but i'm always striving for perfection and
>> performance, and that is why I made my way from mojarra to
>> myfaces, glassfish to tomee/tomcat, and jsf-managed-beans to
>> cdi-managed-beans, and just early this morning from APR to NIO
>> connector.
> 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.
>
>>>> b) Lots of people forget to correctly close external resources
>>>> (files, tcp connections, jdbc resources). Check your source
>>>> code using FindBugs. It is not perfect, but will give you lots
>>>> of warnings if you run on risk of not correctly closing
>>>> resources. Remember, for jdbc resources, you should close all
>>>> result sets first, then all statements, then all connections
>>>> (not all database drivers will release resultset resources on
>>>> statement close!).
>> backtracking... is this a chance/time to use jdbc interceptors?
>> i've seen some chatter about jdbc interceptors, but have not really
>> dug into it quite yet.
> That depends upon what you want to accomplish. You can get messages
> about JDBC resource management problems without writing any
> interceptors at all.
>>>> c) Also, we see incorrect thread programming...
>> this sounds good for clusters, right? i'm hoping to use clustering
>> for the app that i've developed.
> 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.

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!

Edson

>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEAREIAAYFAlEMFXwACgkQ9CaO5/Lv0PC0rACgw7bfEDyVZhHr4V5IWPndxM8Z
> bAEAnjhZlD0T6tK4jEI1XkszWmVZ4R85
> =FwGs
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org