We have a cluster with 2 IS’s(v6.5) connecting to a broker. The problem we are facing is, often for some of the documents gets queued up in the client queue. When we re-start the wM broker all these documents are getting processed. Sometimes 1 or 2 docs get missed also. Then we need to reprocess them from their sources. We noticed getting the following error message in the server log when ever these situations arises.
“Error in getting Broker Log length.” Again Im not sure whether this is related to the actual issue. So taking this as starting point we started in our forums.
From some previous postings on this error message we came across suggestions to disable the “WmLogUtil” package in one of the nodes. We did tried that also but no luck. Still the docs are getting queued up after these changes also and we need to restart the broker everytime. Since this in production Customer is keen in putting an end to it and so do we.
Please let me know, has any one else encountered this kind of issue and have fix for this.
Suren,
Are you losing connectivity to your broker? Do you see “starting to poll” messages in your server log? Are you sure you don’t have hung or active threads on the IS side that are holding up the processing of the documents? Check your service usage on the IS when this condition occurs, see if anything is processing and potentially hung/stuck.
There are also some fixes out there for broker on 6.5 that you might want to check out. Seems like this problem has come up before.
I have noticed this message in the server logs before but I am not sure whether it is at the same time of this issue as this message “Error getting log length” used to fill up the logs. But next time I will keep a watch for this message and update you the next time it occurs.
When ever this issue occurs and we check the broker status in the IS admin page it always shows as Connected in both the nodes.
And for your next question regarding threads, there were no active processing threads for these documents could be found in the service usage. The reason I could tell this is, in our subscribing code we have the status log message for each and every step right from the begining of subcription to the end of invocation written to a database which is useful for our support activity to monitor the interfaces. So in these situations we never noticed an INPROGRESS status message from the subcribing services of these documents.
Thanks for throwing some light on this. We need to put a fix in place for this issue as it is getting critical day by day.
Please check the last retrival time when the broker retrived the document.
If it is close by then I think the flow of documents may be high.
If it is not then try to SUSPEND and RESUME the trigger which is subscribing to the documents.
After suspending and resuming the triggers please check whether they are getting cleared or not.
Please try to see the last retrival time when the Broker retrived the documents.
If it is close by then I guess the broker is fine and the flow of documents may be high.
If it is not the case then SUSPEND and then RESUME the trigger which is subscribing the documents in the broker.
After this please check the document queue size in the Broker.