| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Perhaps your app is generating random numbers from multiple threads
and your test program isn’t. From: Krister Jarl
[mailto:kj@xxxxxxxxxxx] Thanks for the reply! I’ll have a look at the archives! I’ve broken out the code generating the branch and run a couple of
million tests without running into a double. In our application this happens
after ~100 dialogs. So I’m kind of confused here. /kj Från: Scott Godin
[mailto:slgodin@xxxxxxxxxxxx] Hi Krister, Sorry for the lack of responses – I’ve never seen this behavior,
but there was some discussion about random number generation on some platforms
a few months back. You may want to try a search through the posting
archives and see if anything rings a bell: http://www.resiprocate.org/Searching_the_Mailing_Lists Scott From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Krister
Jarl Hello again! I still haven’t received any response to this so I’m rephrasing
myself: Has anybody else experienced that reciprocate generates the same
branch for different requests in different dialogs? Is it known to happen? If anybody would have the time to look at this I would much
appreciate it! /kj Från: Krister
Jarl Hi! We’re
experiencing some problems with resiprocate-1.2. The scenario is described
below: Our
implementation sends an INVITE which is answered with 100 Trying. After this we
receive a 200 ok to another INVITE sent to another destination. We respond to
this by calling createDialogAsUAC() and then makeAck(). This works fine in most
cases (99%) but sometimes the ACK gets the same tid as the first INVITE. This
results in an incorrect state and we get an assert at line 253 in
TransactionState.cxx. Any ideas on what might be wrong? Please
find the logs attached. Thanks! /kj |