When you get get lock on the “connected” client, adapter(or another client) may be in the midst of processing an event. This means that adapter got the event, but has not acknowledged that it processed the event successfully.
So after you get the lock, wait for 10 seconds(this could vary depending on document size and network speed among other variables)
and then get try to peek events.
The idea is to give the adapter client time to process the event it acquired from the queue. Since you have locked the client, the adapter cannot get next event till you release the lock.
Just a shot in the dark, but my guess is that between the time you find out how many messages are queued and then lock the q to peek, something else has pulled off one or more messages. If you’re going to peek and specify the number of messages to peek at, you’ll need to pull the oClient.getClientStatsById inside the locked block.
Did you ever get a satisfactory answer to this question? I need to monitor the queue to make sure that nightly loads (via an XML file) proceed correctly.
Maybe there is a command-line tool that does this already? If not, I don’t mind using the API. I know that there may be commercial tools to do this, but there are no funds to buy them…
There is a product called the VIC Queue manager that helps to manage broker events. It is a commercial product that was advertised on this site some time back.
If that doesn’t work, and you have a webMethods advantage account, there are a few tools that you may be able to get:
Document Tracker - Document Tracker is a simple Broker Client that will allow users to publish documents to a Broker, and subscribe to documents from a Broker via a graphical user interface. The Document Tracker utility is primarily designed for debugging purposes.
Broker Monitor Tool - The Enterprise Monitor provides a UI to track traffic through the webMethods Broker. The Enterprise Monitor is primarily used as a design-time debugging tool or to demonstrate Broker functionality.
These downloads are free from advantage but are not supported, so if you have problems with them, you are on your own.
If you are fortunate enough to have an older license of the broker (called Enterprise) there are a few other tools bundled in with the release (5.01) that provide excellent overview of the broker environment. Look for the “manager.”
I’ve heard a lot of negativity relating to the old manager product, but it has helped me out of many a bind when the Integration Server was not available to provide the same services.
Going back to Integration Server, if you need to figure out what has been queued up or processed, you can do so through the admin console of the WmBrokerAdmin package.
And, you could also write an IS service that automatically checks for this and notifies you based on your custom critieria (in your code.)
If all this seems to be too light-weight and you want something that provides more functionality, webMethods provides a Java API and an ActiveX COM API (lightly supported but works great) that you can use to create your own Broker Admin Client. This is the same APIs that the commercial products and the webMethods products use.
Thanks for your response. I’ve actually implemented the functionality that I wanted using the Java API. I just needed to verify the size of the queue at regular intervals. This is needed since our client needs to do batch-uploads using webMethods. Questionable maybe, but it’s the client. This must be done during the night to minimise impact on performance, thus our need to monitor the queues.
I haven’t read all the documentation yet, but it would be very interesting if the API allowed me to get statistics on the number of documents of a given type so that I could create graphs and maybe create alerts if there are too many documents in queues or too few documents flowing through the system.
I know and use the manager, monitor, and adapter_manager, but they are of no use for automatic monitoring. I definitely do not want to get up during the night to verify. (Mind you, if they would really pay me the out-of-work hours I might think again.
The VIC Queue Manager definitely seems interesting. It remains to be seen if it is just a GUI or whether it allows me to call it from scripts to automatise. I suppose that it uses the APIs underneath?
It definitely would be interesting to use it in some special cases; for instance, to block certain document types in a given client queue but to let others pass. Then again, I haven’t seen the possibility of doing so in the API so I don’t know if the VIC QM can do it. What do you think? Have you used the product? Is it reasonably priced?
>>
I haven’t read all the documentation yet, but it would be very interesting if the API allowed me to get statistics on the number of documents of a given type so that
>>
API doesn’t provide any simple means to do this.
Only way to do the above would be
Create client
peak events and get the type name and have a counter for each event type.
>>It definitely would be interesting to use it in some special cases; for instance, to block certain document types in a given client queue but to let others pass.
>>
You are right. API doesn’t have facility to do that kind of thing.
If you want to implement this, you will have to come up with logic. For example, a place holder queue(custom client) which will receive all the events, consume/delete or fwd the unwanted events to error/dump queue. The event to be processed should be forwarded to the original queue. You can also have flag in the event to mark it(that it has been processed by place holder queue) to facilitate subscription filtering. (Required if you are using pub/sub instead of deliver)
>>
API doesn’t provide any simple means to do this.
Only way to do the above would be
Create client
peak events and get the type name and have a counter for each event type.
>>
Yes, but when (at what interval) do you peek to avoid missing events?
For simply graphing the number of events flowing through our system I thought I had found a much simpler way in the BrokerAdminClient.getEventTypeStats()' method: I tried it on all event types in the scope ActiveWorks::IntegrationComponents’ (since that seems top correspond to the `Integrations’ tab in the adapter_manager. Unfortunately, this returned zeros in all fields of interest to me…
Basically, for starters, I’d be pretty happy to get hold of the Executions' field in the Integrations’ tab in the adapter_manager to have an idea of the number of documents of each type in the system. This will allow me to correlate with any performance issues and to gain an idea about the evolution of the volumetry so that we can suggest hardware upgardes in time.
Hm! Now that I try again with all the event types I notice that there are other event types for which there are non-zero values. I don’t understand why though…
