-
15. Re:
Hi Andy,
Thanks for the pointers. Based on your suggestions I have been able to send and receive 1000 messages on my Windows XP box without any problems! I tried to push this number upwards but it breaks at about 3000 messages - same "Connection failure has been detected" message. Anyway, I am not worried about that right now since I am not expecting those kinds of loads on my system. Moreover, it may just be that I am running out of steam on my development laptop.
Bottom line is that my MDB configuration has always been correct. As you indicated, since I am running in my local server, I can just use the default INVM settings and there is no need for netty. So I have reverted to the simple MDB configuration I previously had:@MessageDriven(activationConfig={ @ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"), @ActivationConfigProperty(propertyName="destination", propertyValue="queue/jmstest") }) public class TestMessageListener implements MessageListener { ... }
The problem really was on the sender side. As Tim pointed out, because I was using "/ConnectionFactory", I was really not going through the JCA adapter. As soon as I changed that to "java:/JmsXA", messages started flowing smoothly. So I am a happy camper now :-).
Couple of quick followup questions:
1) When I monitor my queue from JBoss jmx-console I see very low message counts, typically less that 50. I know that all my 1000 messages have been pumped into the queue because the call to send them has returned. I also know that only a handful have been received by watching the logs. So why does the console not show a big number in the queue?
2) In the stand-alone server use case, where is the connection factory located - on the JBM server or on client (i.e. a standalone application or servlet/EJB running on an application server)? I am assuming that it is on the client and you might even provide an implementation that manages a pool of connections just like the JCA adapter on the application server. Is this assumption correct?
Finally, I have couple of suggestions that would make the documentation a lot clearer - at least for me :-). I like the two diagrams in sections 3.3 and 3.4 - they give a nice high level overview of the two use cases - standalone and embedded. I suggest showing an external client in the standalone case to make it crystal clear from where the services are accessed.
Next, I would use these diagrams as a base for explaining deeper concepts. Overlay them with connection factories to show where they are located and how many of them are there. Especially useful would be to show what we get "out-of-the-box". For example, I had no idea that we get the JmsXA factory out-of-the-box and it is a JCA factory that I can start using right away. The documentation leads me to believe that I got to do a #~it-load of configuration before I can get JCA working - which is absolutely not true.
Finally, it would be very helpful to use the diagrams to show which configuration file controls which piece. There are so many configuration files flying out there that it is confusing for a beginner. You guys have set up very good defaults so that a new user could get started in just 10 minutes, but it has taken so much energy for so many people to get a simple use case going. I guess if you create a 10 minute getting started guide for two use cases (embedded and stand-alone), that would go a long way! (The existing Quick Start Guide is very mechanical, it gets the examples running but leaves the reader without any context around what they did. Also, I was having problems getting the jca-config example to run because of couple of issues - I could provide details separately.)
I hope this is feedback constructive.
Thanks again for all your help.
Naresh -
16. Re:
1) When I monitor my queue from JBoss jmx-console I see very low message counts, typically less that 50. I know that all my 1000 messages have been pumped into the queue because the call to send them has returned. I also know that only a handful have been received by watching the logs. So why does the console not show a big number in the queue?
This could be for 2 reasons, either the messages haven't arrived in the queue yet (this could happen if paging kicks in) or the messages are sitting in the clients internal buffer.2) In the stand-alone server use case, where is the connection factory located - on the JBM server or on client (i.e. a standalone application or servlet/EJB running on an application server)?
I'm not 100% sure what yopu mean by located. The connection factories are configured and created on the server and serialized to the client on lookup. The instance being used is on the client side.I am assuming that it is on the client and you might even provide an implementation that manages a pool of connections just like the JCA adapter on the application server. Is this assumption correct?
This we already do, see the 'Session Multiplexing' chapter.
regarding the documentation, we will be reviewing this again before GA and will nore your comments. -
17. Re:
"nbhatia" wrote:
Thanks for the pointers. Based on your suggestions I have been able to send and receive 1000 messages on my Windows XP box without any problems! I tried to push this number upwards but it breaks at about 3000 messages - same "Connection failure has been detected" message. Anyway, I am not worried about that right now since I am not expecting those kinds of loads on my system.
I am worrried though since that should never happen, irrespective of load. Clebert and Andy are the guys who have access to Windows boxes. Hopefully one of them will try and replicate this.
1) When I monitor my queue from JBoss jmx-console I see very low message counts, typically less that 50. I know that all my 1000 messages have been pumped into the queue because the call to send them has returned. I also know that only a handful have been received by watching the logs. So why does the console not show a big number in the queue?
The messages probably aren't in the queue, they're buffered on the client waiting for consumption. If you don't want buffering you can turn this off, see http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta3/html_single/index.html#flow-control.consumer.window
Next, I would use these diagrams as a base for explaining deeper concepts. Overlay them with connection factories to show where they are located and how many of them are there. Especially useful would be to show what we get "out-of-the-box". For example, I had no idea that we get the JmsXA factory out-of-the-box and it is a JCA factory that I can start using right away. The documentation leads me to believe that I got to do a #~it-load of configuration before I can get JCA working - which is absolutely not true.
Well, you don't get it out of the box with JBoss Messaging. The thing at java/:JmsXA is the JBoss app server is the JMS JCA resource adapter - it's not part of JBoss Messaging is part of the application server and is there irrespective of whether you have installed JBM or not. The JBoss AS JCA adapter can be used with other messaging implementations too.
Finally, it would be very helpful to use the diagrams to show which configuration file controls which piece. There are so many configuration files flying out there that it is confusing for a beginner.
Certainly JBoss application server has many configurations files, but JBoss Messaging actually has very few, just:
jbm-configuration.xml - this is the main config file with most stuff in it
jbm-users.xml - this is the default user credential file - you probably won't even use this when using jboss as
jbm-jms.xml - this just contains JMS destinations and connection factories, you won't use this if you're not using JMS
You can actually run a fully functioning server with just jbm-configuration.xml.
The purpose of all the above files are explained in http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta3/html_single/index.html#using-server.configuration
Any other files you have configured (e.g. jms-ds.xml) are not part of JBoss Messaging - they're JBoss Application Server config files and should be described in the JBoss AS documentation.
Thanks for your feedback it's very constructive. -
19. Re:
Andy and Tim, thanks for answering my questions. I guess I was not very clear on the boundaries between JBM and JBoss, so your explanation was very helpful. Since many users will use JBoss and JBM together, I suppose including that explanation in the manual would also be very useful.
I have reopened https://jira.jboss.org/jira/browse/JBMESSAGING-1677 and attached my latest code to it. The configuration steps are included in readme.txt. Andy, if you need any more information please let me know.
Thanks.
Naresh -
20. Re:
"nbhatia" wrote:
Andy and Tim, thanks for answering my questions. I guess I was not very clear on the boundaries between JBM and JBoss, so your explanation was very helpful. Since many users will use JBoss and JBM together, I suppose including that explanation in the manual would also be very useful.
Agreed, especially for users using JBM in JBoss AS, it's easy to just think of everything as just "JBoss". We should add some clarification in the documentation. Thanks again for your good feedback :) -
21. Re:
"timfox" wrote:
"clebert.suconic@jboss.com" wrote:
Take a look at jms-ds.xml
The JNDI is java:/XAConnectionFactory.
(You need to use the local JNDI for that... just do new InitialContext(). As you may known java:/ means local VM).
you can just do:InitialContext ctx = new IntialContext(); ConnectionFactory cf = (ConnectionFactory)ctx.lookup("java:/XAConnectionFactory");
That is NOT correct.
If you lookup java:/XAConnectionFactory you will NOT be using JCA.
There is a section on using JCA in the docs:
http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta3/html_single/index.html#d0e5931
Yes.. I remember that now...
What confused me was the JMSProviderLoader that still on the jms-ds.xml:<connection-factories> <!-- JMS Stuff --> <mbean code="org.jboss.jms.jndi.JMSProviderLoader" name="jboss.messaging:service=JMSProviderLoader,name=JMSProvider"> <attribute name="ProviderName">DefaultJMSProvider</attribute> <attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute> <attribute name="FactoryRef">java:/XAConnectionFactory</attribute> <attribute name="QueueFactoryRef">java:/XAConnectionFactory</attribute> <attribute name="TopicFactoryRef">java:/XAConnectionFactory</attribute> </mbean> <!-- JMS XA Resource adapter, use this to get transacted JMS in beans --> <tx-connection-factory> <jndi-name>JmsXA</jndi-name> <xa-transaction/> <rar-name>jms-ra.rar</rar-name> <connection-definition>org.jboss.messaging.ra.JBMConnectionFactory</connection-definition> <config-property name="SessionDefaultType" type="java.lang.String">javax.jms.Topic</config-property> <config-property name="JmsProviderAdapterJNDI" type="java.lang.String">java:/DefaultJMSProvider</config-property> <max-pool-size>20</max-pool-size> <security-domain-and-application>JmsXARealm</security-domain-and-application> </tx-connection-factory> </connection-factories>
-
27. Re:
An easy way to replicate this on my Linux Desktop:
Send 100K messages using Naresh's testcase.
The MDBs will be receiving messages over XA.
I got the eventual exception:
javax.jms.JMSException: MessagingException[errorCode=3 message=Did not receive ping from server]
One thing I realized, was during the processing.. the MDB is consuming messages over XA, so I got lots of small transactions processing...
on the client:"Thread-13 (group:JBM-client-global-threads-1127086624)" daemon prio=10 tid=0x00007f6d263e0000 nid=0x626f waiting on condition [0x000000004648e000..0x000000004648eb80] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00007f6d59f3bc98> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2054) at org.jboss.messaging.core.remoting.impl.ChannelImpl.sendBlocking(ChannelImpl.java:308) - locked <0x00007f6d59f3bcf8> (a java.lang.Object) at org.jboss.messaging.core.client.impl.ClientSessionImpl.commit(ClientSessionImpl.java:810) at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:811) at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2656) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1784) - locked <0x00007f6d633e0a88> (a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:94) at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177) at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1423) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:137) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) at org.jboss.messaging.ra.inflow.JBMMessageHandler$XATransactionDemarcationStrategy.end(JBMMessageHandler.java:544) at org.jboss.messaging.ra.inflow.JBMMessageHandler.onMessage(JBMMessageHandler.java:287) at org.jboss.messaging.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:671) at org.jboss.messaging.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:41) at org.jboss.messaging.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:788) at org.jboss.messaging.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)
and on the server:"Thread-9 (group:JBM-server-threads799626944-377384882)" prio=10 tid=0x00007f6d379f3000 nid=0x627c waiting on condition [0x000000004719b000..0x000000004719bc00] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00007f6d6340ae90> (a org.jboss.messaging.utils.VariableLatch$CountSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:905) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1217) at org.jboss.messaging.utils.VariableLatch.waitCompletion(VariableLatch.java:120) at org.jboss.messaging.core.journal.impl.TransactionCallback.waitCompletion(TransactionCallback.java:56) at org.jboss.messaging.core.journal.impl.JournalTransaction.waitCompletion(JournalTransaction.java:379) at org.jboss.messaging.core.journal.impl.JournalImpl.appendPrepareRecord(JournalImpl.java:1210) at org.jboss.messaging.core.persistence.impl.journal.JournalStorageManager.prepare(JournalStorageManager.java:411) at org.jboss.messaging.core.transaction.impl.TransactionImpl.prepare(TransactionImpl.java:166) - locked <0x00007f6d6340abd8> (a java.lang.Object) at org.jboss.messaging.core.transaction.impl.TransactionImpl.commit(TransactionImpl.java:208) - locked <0x00007f6d6340abd8> (a java.lang.Object) at org.jboss.messaging.core.server.impl.ServerSessionImpl.doHandleXACommit(ServerSessionImpl.java:1738) at org.jboss.messaging.core.server.impl.ServerSessionImpl.handleXACommit(ServerSessionImpl.java:545) at org.jboss.messaging.core.server.impl.ServerSessionPacketHandler.handlePacket(ServerSessionPacketHandler.java:168) at org.jboss.messaging.core.remoting.impl.ChannelImpl.handlePacket(ChannelImpl.java:621) at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:364) - locked <0x00007f6d5a1c94c0> (a java.lang.Object) at org.jboss.messaging.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:483) at org.jboss.messaging.core.remoting.impl.invm.InVMConnection$1.run(InVMConnection.java:136) at org.jboss.messaging.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:105) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619)
Maybe this specific usecase is holding of pings and pongs because of the locks during the XA commit?