MQdev Blog - moving to Messaging on Developerworks!
The WebSphere Messaging and Connectivity User Group South Asia (http://www.websphere.org/websphere/Site?page=ugdetail&groupId=152) is meeting in Bangalore on the 9th June 2009.
You can register in this User Group here (Join this User Group button on the website) -> http://www.websphere.org/websphere/Site?page=ugdetail&groupId=152
The details of the event planned for the 9th of June 2009 are now available on the UG website -> http://www.websphere.org/websphere/Site?page=ugdetail&groupId=152#1448
To register for the meeting, please go to https://www.websphere.org/check_user?type=meeting&meetid=1448
The details of the sessions in the event will be available on the website in the first week of June.
In case you face any sort of difficulty in logging in to the website, please feel free to get in touch with me at "firstname.lastname@example.org" (H R Sridhar)
Windows perfmon is an ubiquitous tool for System administrators monitoring various system parameters. Among the host of parameters that can be monitored, WebSphere MQ queues are included too. This post tells you more.
There are four vital WebSphere MQ queue parameters that can be monitored with perfmon.
1. Queue depth
2. Percentage of queue depth
3. Inward traffic to a queue - in terms of number of messages per second.
4. Outward traffic from a queue - in terms of number of messages per second.
To monitor any of these parameters, load the Windows Performance Monitor using the perfmon command. Right-click on the graph area and choose Add counters... to continue. Choose MQSeries Queues from the Performance objects drop down list. Choose the parameter and the queue and you wish to monitor and get started.
Alright. But why aren't all my queues shown ?
Not all queues are available for monitoring. The following set of conditions must match for a queue to be available for monitoring.
1. Queue must be a local queue.
2. The queue must have atleast one message in it OR there must be activity in the queue at the time Add Counters... was clicked.
3. Of course, the queue manager holding the queue must be in the running state.
How about Windows 64 bit ?
Windows 64 bit operating systems come with 2 versions of the Performance Monitor - one 64-bit and a 32-bit version. You will be able to monitor WebSphere MQ queues only with the 32-bit version of the Performance Monitor on a 64-bit machine. This is because the Performance Monitor interface for WebSphere MQ is a 32-bit DLL. And finally, if you'd want to figure out where to find the 32-bit version of the Windows Performance Monitor on a 64-bit machine, look into <Windows Install Dir>\syswow64
The WebSphere MQ documentation for the performance monitor interface is available here (MQ v6) and here (MQ v7)
Often OSGi/Lotus XPD users hit with a timeout warning when they try running their bundles which have activators and googling doesn't help much!.
Below is the complete exception that I have come across.
2009/03/30 20:53:08.234 WARNING While loading class "progress.message.strm.util.BufferedStrmInputStream", thread "ClientListener $CONNECTION$ admin" timed out waiting (5000ms) for thread "Thread[OSGi Console,5,main]" to finish starting bundle "update@../../../../../../vijay/eclipse-6.2/WMQ/com.wmq.jms.bindadminobjects/ ". To avoid deadlock, thread "ClientListener $CONNECTION$ admin" is proceeding but "progress.message.strm.util.BufferedStrmInputStream" may not be fully initialized. ::class.method=unknown ::thread=ClientListener $CONNECTION$ admin ::loggername=org.eclipse.osgi
org.osgi.framework.BundleException: State change in progress for bundle "update@../../../../../../vijay/eclipse-6.2/WMQ/com.wmq.jms.bindadminobjects/" by thread "OSGi Console".
at java.lang.J9VMInternals.verifyImpl(Native Method)
The above exception means that when you have bundle 'A' trying to load classes from another bundle 'B' while it is starting, and that other bundle 'B' depends upon bundle 'A'. As seen in the exception message OSGi runtime skips the loading of the bundle that takes too much time in order to avoid dead lock and proceeds further.
This usually occurs due to bad OSGi programming.
The start method of any Activator is meant to be used to initialize values and run quick actions. If longer actions are required then user should be spawning a thread to carry them out.