< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

RE: [reSIProcate] assert in TransactionState::sendToWire under load


I was not doing that earlier. I added the code but still see the assert.


On Fri, 2005-09-09 at 16:11 -0400, Scott Godin wrote:
> Are you ensuring that each branch is unique?  Ie:
> 
> msg.header(h_Vias).front().param(p_branch).reset();
> 
> Also - if you are using Windows (and old versions of resip) - you must
> make sure each thread creating/sending requests seeds the random number
> generator.
> 
> Hope this helps.
> 
> Scott
> 
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Sandeep Sharma
> Sent: Friday, September 09, 2005 3:55 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [reSIProcate] assert in TransactionState::sendToWire under load
> 
> Hello,
> 
> I am still seeing this assert fire under a load test.. The assert is in
> TransactionState::sendToWire (for a client non-invite). In the following
> code, the assert that fires is "assert(mTarget.getType() !=
> UNKNOWN_TRANSPORT);"
> 
> Poking into the core, I found this in the mDnsResult:
> mTarget = "dev5.corp.jabber.com"
> mSRVKey = "_sip."
> mTransport = TLS
> mPort = -1
> pType = Pending
> 
> Of course this->mTarget is some default value, with type =
> UNKNOWN_TRANSPORT. Looks like it has not been assigned any value after
> the object was constructed.
> 
> It appears that a DNS query for dev5.corp.jabber.com is still getting
> resolved when a second message is sent on the same TransactionState.
> Under what conditions can this happen?
> 
> Related: When is TransactionState deleted? I am assuming SipStack takes
> care of it.
> 
> The scenario is that a a lot of users are logging in, resulting in a lot
> of SUBSCRIBEs getting generated and sent out. What can I do to ensure
> that each of these SUBSCRIBEs gets a unique TransactionState object? In
> my application code, I am not using DUM. But I am adding the Via header
> and branch parameter. I am using resiprocate version from April since
> 0.9.0 did not work well for me. Under functional test, everything seems
> to work fine.
> 
> Any help is appreciated since this is holding up an important release.
> 
> 
>    else if (mDnsResult == 0 && !mIsCancel) // no dns query yet
>    {
>       StackLog (<< "sendToWire with no dns result: " << *this);
>       assert(sip->isRequest());
>       assert(!mIsCancel);
>       mDnsResult = mController.mTransportSelector.createDnsResult(this);
>       mController.mTransportSelector.dnsResolve(mDnsResult, sip);
>       assert(mDnsResult); // !ah! is this really an assertion or an
> error?
> 
>       // do it now, if there is an immediate result
>       if (mDnsResult->available() == DnsResult::Available)
>       {
>          handle(mDnsResult);
>       }
>    }
>    else // reuse the last dns tuple
>    {
>       assert(sip->isRequest());
>       assert(mTarget.getType() != UNKNOWN_TRANSPORT);
>       if (resend)
>       {
>          mController.mTransportSelector.retransmit(sip, mTarget);
>       }
>       else
>       {
>          mController.mTransportSelector.transmit(sip, mTarget);
>       }
>    }
-- 
Sandeep Sharma <ssharma@xxxxxxxxxx>