I have developed an utility to monitor our broker queue for any documents pending there for a certain time. If found it is going to alert our support team with a mail. For this I have used a service from wm.broker.admin package which is been used in the broker admin page to get the client Q’s info. It is working fine.
The reason for this utility is, right now we are facing an issue in our broker docs are getting stuck and once we notice it and restart the broker the docs get going, But now we are doing manually monitoring the broker admin page, which sometimes we miss to monitor it. We are already working with an SR with wM support. But untill they provide a solution, I’m planning to implement this utility to monitor the broker Q as we dont want to miss the time and the docs pending in the Q for long times.
My question is, is there any harm in using this service in my code to monitor. Will it affect any other original functionalities.?
Please advice on this as I look forward to implement ASAP.
Is this creating additional IS sessions when you try to fetch broker queue length?
If yes then I would recommend to optimize your code to use the same session or kill session everytime you check broker queue length as it will end up creating multiple sessions in IS.
Also confirm this with Softwarte AG guys once before you implement this on Production as it might lead to support issues.
I also thought about the IS sessions issue and Im just trying to find out whether it is creating sessions are not, so I tried connecting to the Production broker from my IS QA box and I was able to connect and fetch the Q length. Do you still think even if I connect from QA also, the IS sessions would create problems?
Even if you call from QA box, you would be calling a service on production (correct me if am missing anything)
This would create a session every time you make a call assuming you would be making a call to get queue length every unit of time interval.
We had a monitoring tool which had one functionality to do exactly the same thing and we found out that after couple of days the IS sessions went upto 1000+ and IS started responding slowly.
Well we had a tough time to sort out how to make session singleton or kill session after we use it.
Another suggestion, would be to apply the latest fixes for the Broker on the Production IS.
I’ve experienced this problem before where the queue lengths haven’t gone down. We applied SP3 on the IS and also patched the Broker with the latest fixes from Software AG
I would be calling the service on QA IS not on Production IS. While exeuting the service we have an option to mention it to which broker it has to connect and I specify the Production broker.
So my idea is , even if it creates multiple IS sessions, it is going to be on QA IS so the Production IS will be safe. But after your comment on sesisons, need to make sure one more thing also, Does broker also maintain any sessions for all the incoming connections?
And also it would be great if you could share the way that you sorted out to make the sessions singleton or killing the sessions after use. This would give me good start for me to research on this.
Exactly thats what Im looking into it now about the broker clients. If we could succeed in developing this small utility without harming the production systems, it would help the support team to avoid monitoring the broker manually and act on it before the tickets start pouring in.
Sumit: Did you use the Broker Java API to do your Broker interactions? Or did you use the wm.broker.admin services as Suren is doing?
The reason I ask is because the sessions used by the wm.broker.admin services are managed differently than those via the Broker Java API. Basically, they are a pool managed behind the scenes.
Yeah, that makes sense. The easy solution there would be to make the IS service that was called stateless. The IS session would be destroyed on service completion.
Hmm. You lost me there. The Broker doesn’t allow multiple client queues with the same name.
But I guess that’s beside the point. Suren, if you’re using the pub.broker.admin services successfully, then you don’t need to manage the Broker connections explicitly. They will be managed for you. In fact, I don’t think you could manage them yourself even if you wanted to as the session management is behind the scenes. Keep in mind too, that I don’t think the pub.broker.admin services are public either–support won’t help you if you run into trouble and they may go away at some point in the future.
Can you share more of your implementation approach? Perhaps we can identify possible issues, if any.
Just a quick recap of the reason behind this utility. We had an issue with the broker where in, somtimes(often) the docs get stuck in the Q and go un-noticed untill the business comes back with a ticket that data didnt reach them yet. So we had to monitor it manually. But as we support across timezones of India and US, we ran into troubles in the delta time. I had already raised a thread in our forums regarding this issue and I remember you have suggested me to monitor the IS logs at these times. But I couldnt as we had some dev work came up. So I ended up creating this service untill we get a solution for this. So I thought I wll get it reviewed before I implement this.
To be precise I used the following service to get the client information.
“wm.broker.admin.clients:getClientInfo”. As this is goin to be an internal monitoring tool and I was not aware of the session management, I did not want it to go into production server.So I executed this service from QA IS by giving the PROD broker details and it worked. Follwoing is the pseudo.
wm.broker.admin.clients:getClientInfo.(gives list of clients and their client Q info).
loop over clients list.
3.check for Q size if more than 0
4.then “wm.broker.admin.clients:getClientSubscript” (gives more info abt the subscription docs)
check whether this client is connected or not(branch on a booleon)
5.Alert by email with teh details.
endloop.
This is the approach I ve choosen. It works fine. Now Im trying to calculate the age of the docs in Q before alerting.
And the services I mentioned above are appearing in the Developer.Are they still not public?
Please check if anything in this approach might harm the prodcution systems.
Sounds like you need a queue depth monitor that checks the age of the last retrieved time from the queue. The Broker API does this quite well and will not cause any additional overhead on the broker if implemented correctly. Plus if the IS is the reason your documents are not moving through the queue, then you monitor does not depend on the IS functioning correctly. The broker admin API will allow you to do this.
You’ll obviously want to test this out in a test environment that is as close to production as possible, but I don’t see any real issues with your approach.
The services are visible in Developer, but they are not documented and I don’t believe they are intended for our direct use.
Suren is using service from developer I lost it there.
Raemon :
Sorry following might be completely off the topic what Suren wants but thought of explaining what we did and what was the problem :
What we had done was external mini struts app where we used combination of broker API and IS API…
I think the app created broker client with different client ids but with same name… (I might be completely wrong here, but we had some issue regarding clearing broker clients)
Even I remember if we use multiple instances Document Tracker it creates client with same name and different client ID.