tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edson Richter <edsonrich...@hotmail.com>
Subject Re: Help in diagnosing server unresponsiveness
Date Sun, 03 Feb 2013 11:50:22 GMT
Em 03/02/2013 07:20, Howard W. Smith, Jr. escreveu:
> I definitely do not want to take/lead away from Edson and Mark's
> recommendations and responses related to linux, but as someone that has
> found success with his first-and-only JAVA/JSF web application, running on
> Windows Server 2003 32-bit 4GB, and now Windows Server 2008 R2 64-bit 32GB
> RAM (preparing for future development), one thing I love is ...debugging,
> as that has been my major strength throughout my (almost 20 year) career,
> prior to learning java via (Oracle's) java ee 6 tutorial (summer 2011) and
> beginning java development immediately afterwards. Just wanted to share
> that tidbit, for any/all following my responses from this point on... as
> Edson mentioned earlier, I am definitely 'junior' java developer, now, that
> is loving java/jsf, and learning so much by listening in on topics in this
> mail list. :)

I hope you did not get offended :-) That wasn't my intention - I was 
mentioning I have some "juniors" here (programmers with less than a year 
of experience), and they adopt bad practices all the time (that's why 
used pair programming and code review meetings to get rid of).
Actually, I am learning here as well. The purpose to help is really to 
learn and avoid same problems in future.
By sharing our collective experience we can confirm our hypothesis or 
not - and then construct new knowledge from there.

>
> Anyway, this CPU spike reminds me of when I migrated from JSF-managed-beans
> to CDI-managed-beans and I experienced the cyclic references that is an
> absolute no-no with CDI, and even recently, add some new code to the app,
> which resulted in the same...cyclic reference between 2 existing CDI
> @SessionScoped beans. I had to resolve that on both occasions by a patch
> which included use/reference of Boolean variable, which was initialized in
> @Postconstruct, of course.
>
> Is it possible that your app has CDI involved and any cyclic
> references...that could be causing this CPU spike?

So I learned something new here! Thanks, I'll keep an eye on it :-)

Edson

>
>
> On Sat, Feb 2, 2013 at 11:17 PM, Zoran Avtarovski
> <zoran@sparecreative.com>wrote:
>
>> Hi Howard,
>>
>> The move to linux was part of a move in-house for our client as the web
>> services are only accessible behind the firewall.
>>
>> My gut feeling is that the issue isn't related to the WS as they run on a
>> scheduled task 3 times a day. I think the issue lies in our app and
>> struggling with not being able to see exactly what's happening during the
>> crash. JavaMelody provides some insight but just not enough.
>>
>> I'm quite happy to post the charts for others to see. Just not sure what
>> the best way to do it is.
>>
>>
>> Z.
>>
>>
>>
>>
>>
>> On 3/02/13 3:11 PM, "Howard W. Smith, Jr." <smithh032772@gmail.com> wrote:
>>
>>> I know this is asking for too much or might be impossible to do but
>>> process
>>> of elimination.. If it was possible to eliminate or prevent web services
>> >from executing or being accessed, and no spikes occur, then problem is
>>> there. I think you said earlier that system was stable on Windows and
>>> migration to Linux was driven by the web services requirement. I wonder
>>> what kind of processing in those web services which may be causing this. A
>>> lot of database access, even more database access now because of web
>>> services? Did some developer try to add a manual call to gc, somewhere in
>>> the app to free resources. Maybe you can poll any / all developers or
>>> search code accordingly. Does the spike occur at certain time of day,
>>> maybe
>>> some code executed on schedule, or does it occur after certain activity
>>> occur in the app either by endusers or background processing?
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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


Mime
View raw message