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
<zo...@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." <smithh032...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
