[OpenSIPS-Users] udp receiver processes get stuck on publish

[Kristian F. Høgh]

Hi list,

We've got issues, as our presence server gets locked up.
The following happened on our test server, running opensips 1.11.2
As I can see from our sip-traces and logs, one PUBLISH request was "overtaken" by another.

1. PUBLISH (no etag)  (pid 3012)
200 OK, etag: 1   (pid 3012)

2. PUBLISH, etag 1   (pid 3008)
200 OK, etag: 2   (pid 3008)

3. PUBLISH, etag 2  (pid 3005)
4. PUBLISH, etag 2   (pid 3011)
200 OK, etag: 3  (pid 3011)
200 OK, etag: 4   (pid 3005)

5. PUBLISH, etag 4   (pid 3012)
PUBLISH, etag 4  (retrans)
PUBLISH, etag 4 (retrans)
PUBLISH, etag 4 (retrans)

The database update on 3rd PUBLISH took 6749us according to exec_query_threshold.
The database update on 4th PUBLISH took 3646us.

On the 5th PUBLISH pid 3012 got stuck, while updating presentity.

Half an hour later I noticed, and enabled debug. I got the following:
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: pres_uri= sip:<user>@<domain>, event=5, etag= 4
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = <unrelated>
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 2
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 4
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: pres_uri= sip:<user>@<domain>, event=5, etag= 4
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = <unrelated>
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 2
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: found etag = 4
/usr/local/sbin/opensips[3012]: DBG:presence:search_phtable_etag: pres_uri= sip:<user>@<domain>, event=5, etag= 4
...

The etag <unrelated>, was generated at another call, 7 minutes after the process was stuck.

I've got full sip-traces and log from presence server, if somebody can help.
For now we added a counter to the while loop around line 560 of modules/presence/presentity.c, terminating when it reaches 1000.

Regards,
Kristian Høgh