| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
Hi,Following my previous post on “invalid handles” issue, I was looking at a related page of DUM handls on www.resiprocate.org/DUM_handles in terms of this issue. It seems to me that the ServerPagerMessage(Usage) may get deleted, causing the Handle::isValid() function to return false, according to the description to the DUM Handle.Since the Handle::isValid() function returns false frequently in my application, the ServerpagerMessage object should have been non-existent or deleted frequently before I can use it.I also tested the pure DUM client with the code below and with high messaging trafficvirtual void onMessageArrived(ServerPagerMessageHandle handle, const SipMessage& message){if(handle.isValid()){SharedPtr<SipMessage> ok = handle->accept(200);handle->send(ok);}else{cout << "invalidhandle: " << ++invalidhandle << endl;}}The invalidhandle variable never gets incremented even if there are timeouts. This sort of indicates that how I have used the handle might have be related to this issue.I’m just wondering under what circumstances would the handled object gets deleted by reSIProcate? I mean I may be wrong on how the handle could be used and if that is the case I will need to start over from the beginning.Regards,Alex发件人： he yaxin <crazyplayer1983@xxxxxxxxxxxx>
收件人： Scott Godin <sgodin@xxxxxxxxxxxxxxx>
抄送： "resiprocate-users@xxxxxxxxxxxxxxx" <resiprocate-users@xxxxxxxxxxxxxxx>
发送日期： 2011年12月15日, 星期四, 下午 4:11
主题: RE: FW: invalid handle while queueing DUM commands
Thanks, Scott, for a very prompt reply! I will try them out for sure.In terms of stale handles, I mean the isValid() function of a handle to a specific DUM object(say, ServerPagerMessage) returns false.In various callback functions provided by the DUM, there is a passed in parameter XXXHandle, like ServerPagerMessageHandle, ClientPagerMessageHandle. For instance, when the UA has received a pager message, the onMessageArrived() callback function is called and the application is able to send back the “200 OK” response, using the accept() and send() function from the ServerPagerMessage handle.I have come to a point that isValid() function frequently returns false. I am really stuck at the moment. I really don’t have a clue what could cause an invalid handle.In my application, I store a pointer to the handle for later use. After a response is passed down from the non-SIP server, the stored handle will be retrieved for sending the response to the SIP domain. But the handle gets invalid before I can use it. Do you have any idea on this?Regards,Alex发件人： Scott Godin <sgodin@xxxxxxxxxxxxxxx>
收件人： he yaxin <crazyplayer1983@xxxxxxxxxxxx>
抄送： "resiprocate-users@xxxxxxxxxxxxxxx" <resiprocate-users@xxxxxxxxxxxxxxx>
发送日期： 2011年12月15日, 星期四, 下午 2:10
主题: Re: FW: invalid handle while queueing DUM commands
You could try enabling the RESIP_FAST_STREAMS support for further improvements. Just open resipfaststreams.hxx and comment out the RESIP_USE_STL_STREAMS define line at the top. You could also try with and without the NO_IPHLPAPI preprocessor define - this will cause a different API to be used for determining the source network interface so send from. Previous versions of windows showed the following API: WinCompat::determineSourceInterfaceWithIPv6 which calls getBestInterfaceEx to be horribly slow - not sure if that problem persists in Windows 7 or not though.I'm not sure what you mean by stale handles. If it happens to take DUM longer than 32 seconds to respond to a UDP request, then it the sender will see this as a timeout. What is the CPU like during your tests - is it flooded?ScottOn Thu, Dec 15, 2011 at 7:05 AM, he yaxin <crazyplayer1983@xxxxxxxxxxxx> wrote:
Hi Scott, thanks for your post. I got some solid performance improvements after following your suggestions.A stable rate of 120 successful message req&resp per second was achieved after all console outputs were removed; a stable rate of 240 successful message req&resp per second was achieved after a release binary was used + no console output.My testing environment where the DUM client runs is as follows:Processor: Intel Core 2 Duo CPU P8600@ 2.4GHz 2.4GHz;RAM: 4.00 GB(2.96 GB usable)OS: Windows 7 32-bitAfter getting this, I am wondering is this test result normal on the platform I used? Is it possible that there are some further improvements?This test result brings up another question that I am actually more interested in: In my previous test, is it the fact that the timeout is caused by the response being not generated, which is caused by stale handles, which is ultimately caused by the DUM being slowed down? [i.e. The pure DUM client is slowed down by outputting the console message and the DUM inside my own application is slowed down by waiting for the response from the non-SIP server]. Thanks.Regards,Alex发件人： Scott Godin <sgodin@xxxxxxxxxxxxxxx>
收件人： he yaxin <crazyplayer1983@xxxxxxxxxxxx>
抄送： "resiprocate-users@xxxxxxxxxxxxxxx" <resiprocate-users@xxxxxxxxxxxxxxx>; KizerPhilip <pckizer@xxxxxxxxxxx>
发送日期： 2011年12月14日, 星期三, 下午 4:43
主题: Re: FW: invalid handle while queueing DUM commands
Outputting to the console window for every message will definitely slow things down. Try and remove all console based logging and see what improvements you notice. Some other questions:1. What platform are you testing on?2. Did you build a release/optimized binary?Scott----- 转发的邮件 -----发送日期： 2011年12月12日, 星期一, 下午 5:54
发件人： he yaxin <crazyplayer1983@xxxxxxxxxxxx>
收件人： "resiprocate-users@xxxxxxxxxxxxxxx" <resiprocate-users@xxxxxxxxxxxxxxx>
主题: RE: invalid handle while queueing DUM commands
Hi All,Following up the invalid handle issue in my last post, I was trying to isolate the problem by solely using the reSIProcate’s own code.I was using SIPP to test against a UAS that is based on DUM’s pager message classes. I have got a ServerMessageHandler class derived from ServerPagerMesssageHandler, in which the onMessageArrived() function was overridden like this(standard routine implementation):virtual void onMessageArrived(ServerPagerMessageHandle handle, const SipMessage& message){SharedPtr<SipMessage> ok = handle->accept(200);handle->send(ok);Contents *body = message.getContents();if(body->getType().type() == "text/plain"){cout << "Message RECEIVED: " << *body << "\n";}}I was trying to find out how this piece of code that is using only the DUM code performs to generate the “200 OK” response.The test got started at a rate of 1 message per second(mps) under Wireshar’s monitoring, and the rate was gradually increased. At the rate of 6-7 mps, everything is fine, except that it looks like the DUM begins to fail to keep up with the message sending rate, according to Wireshark. At the rate of about 30 mps, the retransmission begins to appear and it is more significant that the DUM cannot keep up with the request message, but the “200 OK” responses are always received, according to the SIPP statistics. At the rate of 35 mps, timeout begins to appear, together with SIPP’s failing to receive the “200 OK” response.I am not 100% sure if I have written the UAS correctly, but the test kinda shows that the DUM is much slower or more error-prone than the reSIProcate SIP stack itself, as there are many posts online shows that the SIP stack is able to handle thousands of sip messages per second, given that the pager message is just one simple sip message. Also, does the timeout have something to do with the invalid handle issue that I mentioned in my last post? Or has anybody come across the invalid handle issue while queueing DUM commands under high messaging rate to share some possible solutions? Thanks very much.Regards,Alex----- 转发的邮件 -----
发件人： he yaxin <crazyplayer1983@xxxxxxxxxxxx>
收件人： "resiprocate-users@xxxxxxxxxxxxxxx" <resiprocate-users@xxxxxxxxxxxxxxx>
发送日期： 2011年12月7日, 星期三, 下午 3:22
主题: invalid handle while queueing DUM commands
Hi all,I am using the solution of queueing DUM commands to call DUM APIs from different threads.While I was load testing my application, I accidentally found that mHandle.isValid() returned false. And it returned false significantly frequently if the call rate was higher than 3 calls/second. (PS. There is no problem when the call rate was 1 call/second.)I have a ServerPagerMessageCompletionCommand class that looks like thisclass ServerPagerMessageCompletionCommand : public DumCommand{public:ServerPagerMessageCompletionCommand(ServerPagerMessageHandle h, int code) : mHandle(h), mResponseCode(code) {}void executeCommand(){if(mHandle.isValid())mHandle->send(mHandle->accept(mResponseCode));}private:ServerPagerMessageHandle mHandle;int mResponseCode;}The ServerPagerMessageCompletionCommand gets constructed when it is ready to send back a response. The previously stored ServerPagerMessageHandleand response code from the non-SIP server will be passed to its constructor. Since the ServerPagerMessageHandle is getting corrupted when the call rate is high, there is no way to send back a response to the originating SIP entity, causing abnormal behaviors in the SIP domain.My application is primarily about messaging and it is expected the message traffic could be massive, so it is vital for me that every message dialogue is handled properly. Does anyone have a clue on this? How can the mHandle be invalid? Or am I missing something in queueing DUM commands? Thanks very much!Regrads,Alex