On Thu, Aug 12, 2010 at 04:23:39PM +0200, Andreas.Eversberg wrote:

hi,

it would make sense to run database lookup in a seperate thread (with lower priority). but in this case the database request function of openbsc will not have a result at the time they return. it would take some changes of the processes which do database lookups. i think it will be some work, but it can be done.

sure, this asynchronous database lookup is on the TODO list for a long time, but hasn't been implemented yet. The reason for this in turn is that I wanted to make the asynchronous lookup then use the MAP-over-TCAP protocol to actually interact with the HLR. And in order to do that, the libosmo-tcap etc. has to be verified and stable - which I'm more or less into now.

The idea also was to do this new asynchronous lookup + TCAP/MAP stuff, plus the corresponding HLR first from the SGSN, as OsmoSGSN is more experimental than OpenBSC. Once it works in OsmoSGSN, I intended to port it to OpenBSC.

Now, making OpenBSC deal with an asynchronous lookup and interfacing it with MAP and a more-or-less real HLR are two separate issues, so I don't mind that. However, spawning extra threads in OpenBSC is not something I'm particularly happy about. It is written as a single-threaded program, and that's intentional.

If the counters cause problems, we can either simply put them into a completely different database, or forget about the counters (disable them by default). If that solves the problem, I think it is not worth doing some kind of hacks (like a DB thread within OpenBCS) and simply go for the "real" solution with external HLR process and communication over MAP/TCAP/SCCP

Regards, Harald