Re: [reSIProcate] Mapping SipMessage to TransactionState
On 9/13/05, Sandeep Sharma <ssharma@xxxxxxxxxx> wrote:
> Hello,
>
> Thanks for the explanation. On further testing, I find that under a load
> test, I always end up with a scenario when the transaction id is
> repeated. An example: A SUBSCRIBE was sent, it was assigned a
> transaction id (getRandomHex()), and stored in transaction map. While we
> are still waiting for the response for this (after about 12 seconds),
> another message, (say INVITE) gets allocated the same transaction id as
> the earlier SUBSCRIBE causing all sorts of asserts.
>
> So I am seeing strong evidence that the getRandomHex() is not returning
> "unique" values, which is against the intended behavior as per my
> understanding of the stuff. It always seems to happen under load test.
>
> Before I dig more into it, I would like to ask if anyone has seen this
> sort of issue. Anything I could be missing at the application layer? I
> am not using DUM, using version of resiprocate from April. I am calling
> reset() on the branch parameter on the Via header of all my messages.
Can you please provide an ethereal trace showing the behavior.