RE: [reSIProcate] Load test: assert fromresip::TransactionState::sendToWire
A bug was definitely fixed around this code. Unfortunately for you - it
was fixed in the newer code base (with the DNS caching stuff). You
could do a diff on TransactionState.cxx and try to port the fix back to
the release you are using. Look at changes in the SendToWire method.
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
Fischl jason
Sent: Monday, August 22, 2005 8:54 PM
To: Sandeep Sharma
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Load test: assert
fromresip::TransactionState::sendToWire
Can you post your resip.log with logging set to STACK or at least DEBUG?
The latest stack including 0.9 release has dns caching.
Jason
On 8/22/05, Sandeep Sharma <ssharma@xxxxxxxxxx> wrote:
> Hello,
>
> I posted this a few months back also but could not get any response.
> Basically I have an application that uses resiprocate (does not use
dum)
> to exchange presence and messages with another SIMPLE entity.
>
> Functionally it works wonderfully. It has been running for 3 months
and
> no issues.
>
> When I run a load test which basically logs in a lot of users in a
short
> period of time, I see this assert from TransactionSate. Something
about
> UNKNOWN_TRANSPORT. I am using a resiprocate version from late April.
Did
> not update to 0.9.0 since it is too close to release.
>
> I can provide more information if needed. Can someone explain the
> circumstances under which you can see this assert. Code author? As I
> mentioned, it only happens under load test.
>
> Is it related somehow to doing many DNS lookups in a short period of
> time? Is there any DNS caching feature provided by the stack? Right
now
> every request leads to a DNS lookup even if all of them are going to
the
> same destination.
>
> Any help / pointers / suggestions are greatly appreciated. Need to get
> this resolved ASAP..
>
> Thanks
> Sandeep
>
>
> (gdb) where
> #0 0xb6faec81 in kill () from /lib/i686/libc.so.6
> #1 0xb71c221d in pthread_kill () from /lib/i686/libpthread.so.0
> #2 0xb71c253b in raise () from /lib/i686/libpthread.so.0
> #3 0xb6faea24 in raise () from /lib/i686/libc.so.6
> #4 0xb6faff8b in abort () from /lib/i686/libc.so.6
> #5 0xb6fa7f49 in __assert_fail () from /lib/i686/libc.so.6
> #6 0xb10921e0 in
> resip::TransactionState::sendToWire(resip::TransactionMessage*, bool)
> (this=0x81061b0, msg=0xab8636e8, resend=false) at
> TransactionState.cxx:1461
> #7 0xb1087346 in
>
resip::TransactionState::processClientNonInvite(resip::TransactionMessag
e*) (this=0x81061b0, msg=0xab8636e8) at TransactionState.cxx:400
> #8 0xb1083dc9 in
> resip::TransactionState::process(resip::TransactionController&)
> (controller=@0xaed36b4c) at TransactionState.cxx:153
> #9 0xb107f122 in resip::TransactionController::process(resip::FdSet&)
> (this=0xaed36b4c, fdset=@0xac512d34) at TransactionController.cxx:90
> #10 0xb1077638 in resip::SipStack::process(resip::FdSet&)
> (this=0xaed13008, fdset=@0xac512d34) at SipStack.cxx:400
> --
> Sandeep Sharma <ssharma@xxxxxxxxxx>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel