Hi Alexey, I did more testing and here is what I find out! The replace of the
jar in the module dir is not enough..some cache stuff needs to cleaned also,
just like the other guy said. I did a 2 times test on a out of the box
glassfish where before very first start I replace the jar, all went fine.
This time I saw just 2 messages like you said, and after the add of the new
constraint to the table glassfish come down to a 0% cpu usage not like before
where was going to 100%cpu usage(one core) but, on a two day running on my
dev env where I did some deploys from the admin gui, and run just one user
making calles to my rest service, the bug happend again. What is interesting
now is that I see no logging in the logfile but the cpu goes again to 100%,
and I had to bounce the GF process cos was totally not responding... Ma
thinking is that the bug is still there..something moves glassfish to a
starvation lock but now just the warning is missing... Also you mantioned a
way to disable the idle check for the admin http treads request-timeout for
admin-listener: /$ asadmin set
server-config.network-config.protocols.protocol.admin-listener.http.request-timeout-seconds=-1/
is this posible to be done for a normal one?! also if this is posible what is
the scenario then? this idle thread is lost forever and the available pool
threads decrese? This same application runs about 2 year now on a GF 3.0.1
with no problems at all, I like to move to last version cos its really much
faster:) And i know why is having this kind of problems. You rewrite a lot of
stuff I guess...:) Once again thank you for your replay! BR, Blaze
--
[Message sent by forum member 'baze985']
View Post: http://forums.java.net/node/892403