hi all ,
i'm running my JBOSS in cluster without multicasting that means i had configured my JBOSS in TCP ... and i'm running 2 JBOSS on different machine .... but the problem is that my JBOSS starts without any error oe exception but the problem is that they both didnt identify each other ... my cluster-service .xml file is :---
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address -->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<TCPPING initial_hosts="126.96.36.199,188.8.131.52" port_range="5" timeout="3000" num_initial_members="3" up_thread="true" down_thread="true"/>
<MERGE2 min_interval="5000" max_interval="10000"/>
<FD shun="true" up_thread="true" down_thread="true" timeout="2500" max_tries="5"/>
<VERIFY_SUSPECT timeout="3000" num_msgs="3" up_thread="true" down_thread="true"/>
<pbcast.STABLE desired_avg_gossip="20000" up_thread="true" down_thread="true"/>
<pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800" up_thread="true" down_thread="true"/>
<UNICAST timeout="5000" window_size="100" min_threshold="10" down_thread="true"/>
<FRAG frag_size="8192" down_thread="true" up_thread="true"/>
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
according to documents in "initail hosts" i had given the IP of two machines and in machineA has also the same file and in machineB also have the same cluster-service.xml.
pls tell me any solution ....
A connection needs to be closed property to cleanup the ReadTask and WriteTask threads. There is only one ReadTask and WriteTask created per connection along with a thread pool for message delivery. When I run the temporary queue unit tests there are no ReadTask or WriteTask threads at the completion of the test. There are some msg delivery threads that will hang around for up to 60 seconds until the time to live expires.
Create a bug report on the jbossmq project at the following url with your test code so we can see if there is a usage that is leaking threads.
You can enable trace level logging on the org.jboss.mq category to see what is going on with the message delivery to the clients.
Thanks for the reply Scott
Yes, we are aware that a connection has to be closed once it's usage is over. In fact, there are no threads hanging in the server if the clients are all killed. That part of the functionality is working fine. The problem is with the number of threads alive when the clients are still connected to the JBoss MQ server. Though, I'm repeating the steps again, they are more granular, so, here's what we do:
1. Client creates a temporary queue and creates a receiver for this queue
2. It caches the temorary queue in a hashtable (useful as it receives messages from server on the same queue often)
2. Client binds this queue object to the jndi with the queue name
3. Client invokes a statless session bean with the queue name
4. Session Bean creates a string of 100KB (typically)
5. It looks up the queue object from the jndi, for the given queue name.
6. It creates a session and there by a sender for this queue.
7. It sends the message
8. The registered MessageListener on the client gets notified.
Client sends requests to the server for every 100 secs (typically). The next time it tries to send the request, it doesn't create another temp queue. It reuses the same queue that's created earlier. Similarly, the server uses the same sender info that it has created earlier.
Following are the code snippets for your interest:
QueueConnectionFactory qconFactory = (QueueConnectionFactory) context.lookup(qConnFactory); QueueConnection connection = qconFactory.createQueueConnection(); connection.setExceptionListener( new JMSConnectionExceptionListener(serverUrl)); QueueSession session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE); Queue queue; // creating temporary queue queue = (Queue) session.createTemporaryQueue(); queueName = queue.getQueueName(); connection.start(); QueueReceiver receiver = session.createReceiver(queue); receiver.setMessageListener(this); context.rebind(queue.getQueueName(), queue);
holder = new QueueConnectionHolder(); myQueueTable.put(queueName, holder); Queue queue = (Queue) myContext.lookup(queueName); QueueConnectionFactory factory = (QueueConnectionFactory) myContext.lookup(qConnFactory); QueueConnection connection = factory.createQueueConnection(); holder.setConnection(connection); // remember queue connection QueueSession session = connection.createQueueSession(false, sessionMode); holder.setSession(session); // remember the session QueueSender sender = session.createSender(queue); holder.setSender(sender); // remember sender connection.setExceptionListener(this); connection.start();
And finally sends the message this way:
QueueConnectionHolder holder = (QueueConnectionHolder) myQueueTable.get(queueName); holder.getSender().send(message);
We are not sure what could be causing the problem in this code. When I monitored the log on the server today, I still noticed that there are 3 "Begin WriteTask" and 3 "Being ReadTask" statements in the log. When I kill the client, I see all correspondily 3 "End WriteTask" and 3 "End ReadTask" log statements in the log. But if I don't kill the client, these threads are around in the server.
Please advise on this. Meanwhile, I shall also report the test case in the bug report.
Thanks for your time.
Every connection has a read/write task thread so to have 3 you have 3 connections. I only see two so its not clear where the third is coming from. On the server side, you can eliminate on UIL2 connection in favor of a INJVM connection if the session bean and JMS server are collocated. This is accessed using the java:/ConnectionFactory jndi name rather than ConnectionFactory.
In the bug report indicated the os and jvm as the behavior and scalability with the number of threads will depend on this combo.
Thanks for your reply Scott.
We have figured out that the deadlock is because of the method validateSoftReferenceDepth method in MessageCache. We have commented out the calls to that method and the server works fine. We have run 225 clients , each hitting the server every 100 secs for 2.5 days and still the performance is good. So, looks like that solved the problem for us.
I had opened a bug at : http://jira.jboss.com/jira/browse/JBMQ-4
We are using NullPersistenceManager as suggested in one of the wiki pages. Even then there is this business of Soft Referencing happening in the MessageCache. Is this required when there is no requirement for storing the messages?
I shall conduct a similar test with JVMIL and will let you know the results.
Thanks & Regards,
In 3.2.6 you can turn off soft referencing using the JMX attribute "MakeSoftReferences" on the message cache.
By the way, the message cache is used to page messages out of memory, regardless if you want to persist them or not. This is to avoid out of memory conditions.
From looking at the stack trace in the bug, it seems to want to page out a message that hasn't been added to the server yet, which is odd.