Environment
Novell GroupWise 8 Support Pack 2 Hot Patch 1
Novell GroupWise 8 Support Pack 2 Hot Patch 2
BlackBerry Enterprise Server 4.1.7 b68 and earlier
Novell GroupWise 8 Support Pack 2 Hot Patch 2
BlackBerry Enterprise Server 4.1.7 b68 and earlier
Novell NetWare 6.5 Support Pack 8
Situation
- In the POA's web console screen shows the same threads being used and not releasing.
- Some SOAP threads have been tied up for long periods of time, some going for days without closing.
- Following the specific SOAP thread link in the web console, the one that is hung open, shows the "Current Transaction" as being getQuickMessageRequest.
- After a restart of the POA, they often come back and usually on the same user(s).
- getQuickMessagesResponse is too large: [EA04]
Resolution
Updated June 6th 2013 - Fix available in GroupWise 8.0.3.
1. In BlackBerry Enterprise Server v4.1.7 MR1 and later, the getQuickMessageRequest is no longer used as part of RIM's SOAP implementation for BESG.
1. In BlackBerry Enterprise Server v4.1.7 MR1 and later, the getQuickMessageRequest is no longer used as part of RIM's SOAP implementation for BESG.
2. In BESG 4.1.7 b68 and earlier, the BES only uses a SOAP getQuickMessageRequest if it has not received an event notification for a particular user within 15 minutes. It's a fail safe - a way for the BES to ensure that no new items are missed due to configuration issues or problems with event notifications from the Post Office Agent. Under normal circumstances, the getQuickMessageResponse from the Post Office should not contain any items, because the BES should have been notified of the new events as they occurred.
A large getQuickMessageResponse could indicate a problem with the SOAP event notification from the Post Office Agent and should prompt the GroupWise system administrator to identify the underlying issue.
Additional Information
There error is only displayed when the response is greater than 1 MB. Ideally,string allocations should be kept under 64 KB. When large requests are made, the calling code usually times out and reissues the same command over again. Thus before the original call can return a new request is issued. This keeps happening which causes the hung thread problem noted.