[JBoss-user] [Messaging, JMS & JBossMQ] - Re: ReadTask and Write Task Threads in UIL2
Thanks for your suggestion genman. Right now, we are using 3.2.5. How different is 3.2.6 from 3.2.5? Probably I'll have to go through the release notes. Meanwhile, to update you, Scott, we did another round of testing with the JVM IL. The results are excellent. For my testcase, with the same load, in a LAN, the EJB roundtrip call takes around 15 millisecs and JMS call takes around 35 millisecs (on an average). I thought I'd share these with you. But these results are with the commented out code in MessageCache which tries to call validateSoftReferenceDepth function. Now, we will have to bring db into the picture and see the performance. Thanks for your suggestions. Regards, Kalyan. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857825#3857825 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857825 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS & JBossMQ] - Re: ReadTask and Write Task Threads in UIL2
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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857779#3857779 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857779 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS & JBossMQ] - Re: ReadTask and Write Task Threads in UIL2
In 3.2.6 you can turn off soft referencing using the JMX attribute "MakeSoftReferences" on the message cache. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857778#3857778 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857778 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS & JBossMQ] - Re: ReadTask and Write Task Threads in UIL2
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, Kalyan. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857647#3857647 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857647 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS & JBossMQ] - Re: ReadTask and Write Task Threads in UIL2
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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857364#3857364 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857364 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS & JBossMQ] - Re: ReadTask and Write Task Threads in UIL2
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: Client code: 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); Server code: 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. Regards, Kalyan. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857271#3857271 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857271 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] [Messaging, JMS & JBossMQ] - Re: ReadTask and Write Task Threads in UIL2
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. http://jira.jboss.com/jira/browse/JBMQ 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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3857129#3857129 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3857129 --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
