Hi Alexey, thank you for the fast replay! I swap the patch for
grizzly-http.jar but I see no changes at all. Do i have to clean some cache?!
What I did is just stop glassfish remove the jar and add the new one. But the
outcome is the same!! log file filled with this warning every second...
[#|2012-11-17T16:08:33.568+0100|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=25;_ThreadName=Thread-2;|GRIZZLY0
023: Interrupting idle Thread: admin-thread-pool-4848(15).|#]
[#|2012-11-17T16:08:33.568+0100|WARNING|glassfish3.1.2|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=25;_ThreadName=Thread-2;|GRIZZLY0
023: Interrupting idle Thread: admin-thread-pool-4848(24).|#] Like I said
before, I use out of the box glassfish 3.1.2.2 build5 my process of testing
the bug is this one: 1. instal glassfish 2. start the admin web ui 3. create
one jdbc pool and one resource for the this pool pointing to a mysql database
which has a table with about 2gb of data in it. 4. created a single ejb bean
application annotated this ejb bean as @Startup and created one method in it
annotated with @PostConstract, in this method i open a connection to mysql
and I fire a add constraint to the big table. This add constraint in mysql
takes about 45 mins on my machine 5. deploy the app from the aadmin web ui.
On deployment the app stops(goes Idle) waithing for my sql to finish the add
of constraint, and after 15 mins(default time for idle handling in glassfish)
the logfile starts getting the warnning message every half second. During
this period I dont see a big cpu usage from the glassfish process, on my
2core dev machine mysql uses about 50% of one core and glassgish not more
then a 1%. But after the 45mins when mysql recreation of the table is done,
mysql goes to 0% cpu usage and then glassfish takes over with a 100%(one
core) usage.... Restart ofcourse helps:) but if I go prod with this version
Ill get in the problem after couple of hours. In my applicatiosn I do a
restfull calls every 10sec for a small update of data...and some of this call
will end in this kind of loop for sure... Regards, Blaze p.s. Ill give it a
try one more time with the new patch jar...just to be sure...but I think its
going to be the same
--
[Message sent by forum member 'baze985']
View Post: http://forums.java.net/node/892403