We are seeing some strange behaviour with JBoss 3.2.3/Jetty 4.2.14 where under
load the web server stops allocating new requests to idle threads in its thread
pool.
Every new request results in a new thread being created and eventually the
server stops responding with an OUT OF THREADS message
We are currently experiencing a strange problem with truncated content being
downloaded to a browser.
We are running JBoss 3.2.3_Jetty off Redhat 9.
The content we are loading is a frameset containg 7 frames. Each of those
frames reference many js, images, css files.
Every so often one of the
We just saw the same problem occur this week, on the same server at the same time. We
are running 44 nodes so its likely that the problem is environmental i.e O/S,
hardware, etc.
Anyway, thanks for your time. Will upgrade soon nevertheless.
Re: your advice...you're preaching to the converted :)
Thanks for the tip.
We're only able to reproduce this problem in production. Consequently, there has to be
a reason to upgrade more substantial than just giving 3.2.5 a try.
We are currently running 3.2.3 (Jetty). Why would 3.2.5 fix it? Is there a specific
change to the TimeoutFactory in the r
We're seeing behaviour where a server under certain unknown load conditions will block
every request and eventually our server runs out of threads, memory etc.
Performing a thread dump shows that almost every pool thread is waiting on the
newTimeout method in TimeoutFactory. See the thread dump
Found answer, if you call prepareStatement with any arguments other than just the sql
then caching doesn't work.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845876#3845876
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply
Found answer, if you call prepareStatement with any arguments other than just the sql
then caching doesn't work.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845691#3845691
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply
I'm using JBoss 3.2.3 (Jetty) and have just enable prepared-statement-caching by
setting the prepared-statement-cache-size in the datasource descriptor. The setting
however appears to have had no effect, and I can see in the debugger that I keep
getting a new instance of a prepared statement.
I
We are seeing the same behaviour, setting the prepared-statement-cache-size doesn't
seem to have any effect. Is there another setting that needs to be set apart from just
the datasource descriptor?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845416#3845416
I've been profiling the Jive forum software (running under JBoss 3.2.1) and have
noticed that it isn't explicitly closing resultsets. It expects that closing the
statement that the resultset was created from will close the resultset as well.
While this is a Jive problem, I was wondering if JBoss
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3821397#3821397
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3821397
What is the issue with the HSQL db? I'm getting thread leaks as well. Is there a fix?
---
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3821396#3821396
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3821396
Did you find a fix for this, I'm seeing the same behaviour. Thanks in advance.
--
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3820272#3820272
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3820272
In the JBoss 3.2.1 documentation it says...
"One long outstanding bug of JBoss is that on a transact
13 matches
Mail list logo
