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>