Hi,
I only use PostgreSQL, so I'd have no way to test changes made to db_mysql (which is why I only added the APIs to PostgreSQL). That said, I don't believe it will be hard to do and most (if not all) of the PostgreSQL code should be re-usable (although some of the locking stuff might be PostgreSQL specific - but even then there should be MySQL equivalents). If someone wants to do work on MySQL this I'd be happy to help out if I can.
The DB locking stuff (or rather its use in the presence modules - the locking API itself is fine I think) is still something of a work in progress. At the moment the locking is very strict everywhere to ensure that there is no chance of conflicts between processes and servers. It can probably be loosened off a bit in some areas. Loosening up the locking would increase performance, but it is a bit of balancing act finding the minimum set of locking needed to prevent problems.
The db_mode that affects this error should be the PUA one, not the RLS one.
If the problem is occurring in db_mode=0 in PUA there might be a way to fix it by moving the hash table locking around. At the moment the hash table is locked in the insert_htable() function (called sometime after the SUBSCRIBE is sent - that is before the call to tmb.t_request_outside() in send_subscribe()). If the hash table was locked before the SUBSCRIBE is sent and then unlocked after the insertion it wouldn't be possible for the 2XX to be processed (and the dialog converted) before the dialog record exists. The insert_htable() function would need tweaking (perhaps a second argument) so that it can be run without obtaining a lock itself in this case.
The downside to this is that locking the hash table for longer may reduce performance - but if you are seeing this problem perhaps it is necessary?
Regards,
Peter
peter,
thanks for the explanation. i was using in rls db_mode=0 when i saw the error message. i then switched to db_mode=2 for rls just in case you had fixed something there and i haven't seen the error since then although i'm using mysql where your fix should not help.
The temporary dialog record cannot be created until after the SUBSCRIBE has been sent (the call-id and from-tag are generated by the TM module). This means, on a single server with RLS back-end subscriptions over the local loopback, it is theoretically possible for the SUBSCRIBE to be sent and the 2XX generated, sent, received, and processed before the temporary record is created.
i have exactly the above situation, i.e., backend subscriptions are send over loopback interface.
i'll keep on watching if i see the error again with db_mode=2. it would be nice to get your DB API enhancement implemented for mysql too.
-- juha
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users