If we're not (actually, moreover if we do...), you could try to randomly initialize this variable, but with the MSByte of the general (per process) counter with the (mirrored maybe) LSB of process's pid or some other range 'chunking' technique; if they are truly random, I see no reason why they couldn't be initialized with close values in different processes, if you're lucky enough....
WL.
On 10/25/06, Carsten Bock <[EMAIL PROTECTED]> wrote:
Hi Bogdan,
I did not restart the proxy and even if we did, this would not have lead
into an error, because then we would do a database lookup in every case
(unless the ID would be 0).
I know, it should be incremented for every received message and it
should not lead into this error, but in our case it did not work
properly :-(
I am investigating on this issue and keep you'll informed if i find
something.
CU in Berlin,
Carsten
Bogdan-Andrei Iancu schrieb:
> Hi Carsten,
>
> have you restarted your proxy between the two requests with same IP?
> the msg id is initialized in each process with a random value and
> incremented for each received message, so it will loop after ~4
> billions messages :).
>
> regards,
> bogdan
>
> Carsten Bock wrote:
>
>> Hi everybody,
>>
>> I have just seen a strange phenomenon with "msg->id" field, which,
>> according to the source should be unique per thread.
>>
>> From parser/msg_parser.h, line 161:
>> [...]
>> struct sip_msg {
>> unsigned int id; /* message id, unique/process*/
>> [...]
>>
>>
>> We use this field for minimzing Database-Lookups so we do some
>> lookups just once per request. But now we found some very few
>> examples (e. g. maybe 2-3 times per 1000 Requests), were this id was
>> the same for different requests per thread and this caused some
>> trouble on our proxy. I did see, the call-id of the request was
>> different, but the id was the same.
>> The calls were generated by an Asterisk (SIP) calling another
>> Asterisk (E1) via an Cisco Mediagateway.
>> Has anyone else experienced this?
>>
>> Thanks,
>>
>> Carsten
>>
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> [email protected]
>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>
>
>
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________ Devel mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/devel
