Maybe this also relates to the oswego concurrent lib issues mentioned in this
thread:
http://www.jboss.com/index.html?module=bbop=viewtopict=77101
Cheers, Jörg
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3935374#3935374
Reply to the post :
See also
http://www.jboss.com/index.html?module=bbop=viewtopict=77101
Here the solution is to upgrade to the latest concurrent lib 1.3.4.
Please give it a try.
Cheers, Jörg
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3935377#3935377
Reply to the post :
You can configure the maximum memory used by the JMS cache. If there are more
messages, they are written to the backup storage (ie database or file in older
versions).
If the default memory is larger than the memory of your JVM,
then the OutOfMemory comes before the cache decides to swap out
If you have auto-acknowledgement enabled, the client acks every message
received automatically.
If you use onMessage() to process your messages, the ACK is send on returning
from onMessage(). So if you do all your processing inside onMessage(), the
single ACK will be send after each processing
In this JBoss version, oswego-concurrent thread pools are used to process the
messages. Every message picked up is handed over to the thread pool for
processing.
If the thread pool is set to 1 (using maximumSize), the MDB acts as a singleton.
If some reasons a thread from the thread pools
How do you determine CPU utilization?
Perhaps it is scaled by the number of processors, so 25% already means maximum
usage?
Cheers, Jörg
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3888383#3888383
Reply to the post :
What you call branch is the JNDI name of the queue. If you deploy a queue
using the org.jboss.mq.server.jmx.Queue MBean, the JNDI name of the queue is
derived from the MBean name attribute, ie
| server
| mbean code=org.jboss.mq.server.jmx.Queue
|
This lets me think of the following scenario:
If you actually reach the thread limit of 1024, which the error message
OutOfMemory: unable to create new native thread indicates, the your threads
consume 1024 * 1024k of memory for the per process stack.
I.e. in addition to the heap of 1024MByte
In the first quick browse, I noticed that parallel GC does not make much sense
with just 2 processors. It may even slow down things a bit. Use it if you have
4 procs or more.
But this is not the cause of your problem.
In addition, the per thread stack size (-Xss:1024k) seems quite big. How
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864168#3864168
To save you the typing, Adrian.
Jrg
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864206#3864206
Reply to the post :
But not for me:
ERROR
Artifact: Only Group Members Can View Private ArtifactTypes
Perhaps the access is restricted somehow.
Cheers, Jrg
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864203#3864203
Reply to the post :
Dear Adrian,
one last post about this topic, you are not expected to answer this. Perhaps it
is resolved easier if we meet at a JBoss event (training etc.) some day.
Adrian wrote :
| Asking people to look at dead code (3.2.3 is over a year old)
| is not only a waste of their time it has an
Adrian wrote :
| If you are interested in helping the community there is an outstanding
| task to improve this whole area.
|
| See the following link and the related forum post:
| http://jira.jboss.com/jira/browse/JBMQ-10
|
Nice point. But I would to have at least a basic
Dear Adrian,
Adrian wrote : Why do people insist on reporting bugs with old versions?
I did not report a bug, but just asked whether a JBoss patch contained in
release 3.2.6 would fix our issue:
Jrg wrote : Is it possible in UIL2 that several threads try to deliver a
message via onMessage()
Dear Adrian,
Adrian wrote :
| I am Director of Support for Customers, i.e. those people who pay me to
work on their problems. They have paid for me to spend time on their problem no
matter how trivial or which version of JBoss.
|
Agreed. I also get paid by customers to do their work. Its
Hi all,
we are currently using JBoss 3.2.3 in production and have an issue where two
messages arrive in a different order.
The message are sent by a Singleton MDB in the server to a permanent queue. The
client is a Java process having two JMS sessions to the server: one for
receiving and one
Please also note, that using the standard Java GZipOutputStream has some severe
limitations: If you do a flush which is necessary after each serialized object written
to
the stream, you basically loose your complete compression dictionary. The behaviour is
then as if you compress every object
[EMAIL PROTECTED] wrote : No OIL is going away. OIL has some bad synchronization
problems.
| UIL2 is designed to be concurrent.
|
Adrian,
does message of the sort
| [org.jboss.mq.SpyMessageConsumer] WARNING: NACK issued. The message consumer was
not waiting for a message.
|
Adrian,
I am a collegue of Lucas:
Ad 1) We need to use the IL which is fast enough for our purposes
(UIL2 currently isn't as fast as OIL in our specific application)
Ad 2)
We are using Debian Linux, so the hint with Red Hat does not
apply for us.
With our type of application, we have seen a
Hi,
we have seen a related post recently in this forum, where genman analyzed the
situation and
added a fix in the HEAD of Branch_3_2:
anonymous wrote :
| revision 1.14.2.3
| date: 2004/01/13 19:21:25; author: genman; state: Exp; lines: +21 -1
| Throwable / Thread.interrupted must be
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3820417#3820417
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3820417
Hi Robert,
yes, there are two entries where you may configure this. And this also confused me;
see my
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3820426#3820426
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3820426
Robert,
would you like to try it as a per container config?
Joerg
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3820036#3820036
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3820036
Hi,
if I use primary keys to access Entity Beans, I can avoid all database accesses (using
commit
23 matches
Mail list logo
