[JBoss-user] [Messaging, JMS JBossMQ] - JBossMQ threads sharing locally-instantiated objects?
I have implemented a JBossMQ-driven JMS Queue which is answered by a
JBoss-managed pool of Message-Driven Beans; the deployment descriptor allows
the MDB to run in as many as 15 threads simultaneously, so there are usually
multiple instances of onMessage() running at once.
The problem which I'm having is that objects instantiated by onMessage in one
thread appear to be allocated to memory shared with the equivalent object in
another thread, causing data collision problems which would normally be
associated with data race conditions. My onMessage code looks something like
this:
| public void onMessage(Message inMessage) {
| XMLComboObject generator;
|
| ...
|
| generator = new XMLComboObject();
|
XMLComboObject is a custom class which contains multiple instances of XMLTag,
another class I wrote to represent the structure of an XML tree. Each one of
these is a very large object, so any given instance of XMLComboObject consumes
a sizeable amount of memory.
XMLTag contains a method called replaceContents(String tagName, String
newContents) which deletes the current contents of an XML tag withing the
object and replaces them with the new String:
| ...
| replaceContents(String tagName, String newContents) {
| deleteContents(tagName);
| addContents(tagName, newContents);
| }
| ...
|
All of the sources I've read about Java threads indicate that local variables
are inherently thread-safe, as they are allocated on the stack, which is not
shared among threads. However, when I try to dump the contents of the XML tag
from an XMLComboObject associated with one thread, I frequently (but
erratically) find that the values contained within a tag are concatenated with
values which should be associated with another thread. So where I should see:
THREAD ONE VALUES
...
A
...
THREAD TWO VALUES
...
B
...
I often see:
THREAD ONE VALUES
...
AB
...
THREAD TWO VALUES
...
AB
...
The only thing I can think of which could be happening here is that both
threads are running replaceContents simultaneously on the same XMLTag object,
and thus encountering a race condition. This should never be the case, however,
since the XMLTags in question are subordinate to a local variable within
onMessage(), which is (to the best of my understanding) assumed NOT to be
shared among threads.
So is there any way that Java could be attempting to re-use local instances of
the objects that I'm instantiating, and in the process sharing memory which
needs to be local to a given JMS thread? I can't find any documentation for
such a behavior, but it's the only possibility which is coming to mind.
I don't know whether this is a JVM problem (in terms of memory allocation) or a
JBossMQ problem (in terms of thread management). I am running JBoss 4.0.3-SP1
on Java 1.4.2_07-b03.
Thanks,
Branden Smith
(I have also posted this question on the Sun Java Forums:
http://forum.java.sun.com/thread.jspa?threadID=736921tstart=0.)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3944281#3944281
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3944281
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS JBossMQ] - Re: Too many threads for message queue?
For anyone else who might be having this problem: I think I have figured it out. My initial conclusion was correct; JBoss was creating more message threads than it had the heap capacity to support, causing an OutOfMemoryError. The minimum and maximum number of message threads for a standard MDB queue is regulated by the message-driven-bean invoker-proxy-binding in conf/standardjboss.xml: | invoker-proxy-bindings | invoker-proxy-binding | namemessage-driven-bean/name | ... |MinimumSize1/MinimumSize |MaximumSize15/MaximumSize | ... | You can change the default values, or specify custom minimum/maximum number of threads for the MDB(s) in your app by doing the following: 1. Copy the message-driven-bean invoker-proxy-binding from standardjboss.xml into the jboss.xml for your application. Remember to enclose it in invoker-proxy-bindings tags. 2. Change the name tag to something else. 3. Copy the Standard Message Driven Bean container-configuration into your application's jboss.xml. It should look something like this: | container-configuration | container-nameStandard Message Driven Bean/container-name | call-loggingfalse/call-logging | invoker-proxy-binding-namemessage-driven-bean/invoker-proxy-binding-name | ... | container-configuration | Remember to enclose it in container-configurations tags. 4. Change the container-name tag value to something else. 5. Change the invoker-proxy-binding-name tag to reflect the new name of your invoker-proxy-binding. 6. Make sure that all the MDB references in jboss.xml refer to the new container configuration by changing/adding the configuration-name tag: | enterprise-beans | message-driven | ejb-nameSomeMDB/ejb-name | destination-jndi-namequeue/SomeMDBQueue/destination-jndi-name | configuration-nameWhateverNameYouGaveTheContainerConfig/configuration-name | /message-driven | | ... | I think that the process is similar for stateless session beans as well, but might require some research as to how it differs. Relevant links: http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMDB http://www.precisejava.com/javaperf/j2ee/EJB.htm#EJB148 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3935243#3935243 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3935243 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS JBossMQ] - Re: Too many threads for message queue?
The formatting may make it unclear, so note that where I say Remember to enclose in ..., the formats should be, respectively: | invoker-proxy-bindings | invoker-proxy-binding | | /invoker-proxy-binding | /invoker-proxy-bindings | and | container-configurations | container-configuration | | /container-configuration | /container-configurations | View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3935244#3935244 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3935244 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS JBossMQ] - Too many threads for message queue?
Hi, I currently have a JBoss EJB application which employs 7 message queues using MDBs with container-managed transactions, to which messages are posted via JNDI from a stateless session bean within the same application. I have recently begun encountering OutOfMemoryErrors during periods of heavy processing, when large numbers of messages are posted to the queues; running JBoss with Java's heap profiling tools (big performance hit) reveals that the error generally begins to occur when the number of simultaneously running threads reaches 75 to 80. After examining the Java profiler log files, I found a long series of entries like this: | ... | | THREAD START (obj=35c44e0, id = 60, name=JMS SessionPool Worker-0, group=ASF Session Pool Threads) | THREAD START (obj=35bf1d0, id = 61, name=JMS SessionPool Worker-1, group=ASF Session Pool Threads) | THREAD START (obj=35bc0b8, id = 62, name=JMS SessionPool Worker-2, group=ASF Session Pool Threads) | THREAD START (obj=33c2658, id = 63, name=JMS SessionPool Worker-3, group=ASF Session Pool Threads) | THREAD START (obj=33bdfb0, id = 64, name=JMS SessionPool Worker-4, group=ASF Session Pool Threads) | THREAD START (obj=34ff420, id = 65, name=JMS SessionPool Worker-5, group=ASF Session Pool Threads) | THREAD START (obj=34f4ba0, id = 66, name=JMS SessionPool Worker-6, group=ASF Session Pool Threads) | THREAD START (obj=34e3408, id = 67, name=JMS SessionPool Worker-7, group=ASF Session Pool Threads) | THREAD START (obj=33a0708, id = 68, name=JMS SessionPool Worker-8, group=ASF Session Pool Threads) | THREAD START (obj=339bb60, id = 69, name=JMS SessionPool Worker-9, group=ASF Session Pool Threads) | THREAD START (obj=33dc438, id = 70, name=JMS SessionPool Worker-10, group=ASF Session Pool Threads) | THREAD START (obj=33d6558, id = 71, name=JMS SessionPool | | ... | The number of JMS SessionPool threads being initiated (and not closed) leads me to believe that JBossMQ is creating more threads per message queue than my Java memory settings will permit. (I currently have the server running with the default heap floor/ceiling of 128MB/128MB: -Xms128m -Xmx128m.)' Though I might be able to fix the problem by increasing the maximum heap size, it does not seem that this would guarantee that no further OutOfMemoryErrors would occur. My questions are: 1. Does this seem a reasonable / accurate assessment of the problem? 2. If so, is there any way to limit the number of MDB threads which JBoss spawns to handle each message queue? Thanks in advance. Please let me know if I have failed to give enough information. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3934933#3934933 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3934933 --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence,JBoss/CMP, Hibernate, Database] - Re: EJB Database Access stall
One additional piece of information: sometimes, the stalled request eventually fails and produces this exception: | java.sql.SQLException: Closed Connection | at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168) | at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:210) | at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:273) | at oracle.jdbc.pool.OraclePooledConnection.getConnection(OraclePooledConnection.java:189) | at oracle.jdbc.pool.OracleConnectionCacheImpl.getConnection(OracleConnectionCacheImpl.java:251) | at oracle.jdbc.pool.OracleConnectionCacheImpl.getConnection(OracleConnectionCacheImpl.java:163) | | ... (continues) | | It's a fairly long stack trace, but the next line down is from the database connection class constructor from my code. Any ideas? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3914004#3914004 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3914004 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Persistence,JBoss/CMP, Hibernate, Database] - EJB Database Access stall
I recently completed transitioning an RMI standalone application (which operated via naming lookup on rmiregistry) to EJBs running under JBoss 4.0.3. The application makes JDBC calls to a database in order to get user/login information. The problem is that, at seemingly random intervals, requests from the JDBC connection class running on JBoss to the database suddenly start to hang forever, and, in nearly every case, no Java exception is produced in server.log or on the terminal output. The EJBs continue to accept JDNI requests from the associated web application as normal (as evidenced by debug statements), but once the behavior starts, database calls fail to return, producing no error output at all (as far as I can tell), until the JBoss server is restarted and the EJBs reloaded. I believe I have isolated the stall to the following log4j call (as it is the first in the sequence of logger calls in the database-access sequence not to produce log output): | log.debug(About to get a connection (active count= + | ((oracle.jdbc.pool.OracleConnectionCacheImpl)dataSource).getActiveSize() + ,curr-cache= + | ((oracle.jdbc.pool.OracleConnectionCacheImpl)dataSource).getCacheSize()+)); | The reason that I think this to be a JBoss-related problem is that restarting the JBoss server does correct the problem temporarily, and that the older RMI-registry implementation never had such an issue, despite using exactly the same JDBC code. It has been maddening trying to resolve the problem, as it is essentially impossible to reproduce it on command. Increased usage does seem to be some sort of factor, as the problem occurs more frequently during periods of heavy load (every few hours, as opposed to every few days), but I have yet to successfully induce the malfunction by artificially loading the application with requests. Trying to solve this via trial-and-error would therefore be an extremely slow process. Has anyone else had a similar problem with getActiveSize() or getCacheSize() calls blocking indefinitely, or with database calls eminating from JBoss-deployed EJBs randomly starting to stall out? Thanks, Branden Smith [EMAIL PROTECTED] View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=3913845#3913845 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3913845 --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ JBoss-user mailing list JBoss-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-user
