[Serdev] SER-wide IPC/RPC, how?

[Maxim Sobolev]

Jan Janak wrote:
> On 28-05 14:12, Maxim Sobolev wrote:
> 
>>Folks,
>>
>>We are currently investigating possibility to enhance database support 
>>in usrloc module to make it more robust. The idea is that when the 
>>database goes down for some reason, ser should be able to detect it and 
>>switch automatically to memory-only mode. When in this mode it should 
>>from time to time try to re-connect to the db. Once the connection is 
>>restored it syncs in-memory contacts table with that in the db and 
>>switches back to the previous mode.
>>
>>Unfortunately current architecture makes almost impossible to do it 
>>correctly since both timer thread and listening threads perform database 
>>operations. My plan is to restructure the code somehow, so that only 
>>timer thread is allowed to perform db operations, which would require 
>>some way in which listening threads can "wake up" timer thread and ask 
>>it to insert or update specific contact. This brings up question in the 
>>subject: is there any existing way for the listening thread to perform 
>>remote procedure call or queue task for the timer thread and wake it up? 
>>I guess that it can be done using shared memory and semaphores, just 
>>wonder if there any existing APIs that can be re-used or similar code, 
>>so that I will not be re-inventing the wheel.
>>
>>Any ideas or suggestions are highly appreciated.
> 
> 
>   This is how does it work with db_mode 2 of usrloc module with one
>   exception: if database update fails due to some reason, ser does not
>   try to update the same data again, although it is still kept in memory
>   intact. Database reconnections should be handled transparently by the
>   underlying database library (mysql client lib in most cases), but I
>   have some doubts about the reconnecting part because some people
>   already reported that it did not happen for them, I will have to
>   re-check this.
> 
>   Making usrloc to re-try failed updates should be easy to do (althought
>   it requires some changes to usrloc).
> 
>   Listening threads access the database in db_mode 1 only, in db_mode 2
>   all database operations are performed by a timer.
> 
>   Is that what you are looking for ?

Not quite. We need the same functionality for the mode 1 as well, since 
other parts of our system(s) rely on the information in the location 
database being up-to-date, which isn't guranteed in the mode 2 
unfortunately. Of course one can schedule db updating thread to run as 
frequiently as possible (say 1 time per second), but it can increase 
load imposed on the machine running ser.

Also I doubt about correctness of the "transparent re-connection" 
approach, since usrloc in fact should be notified in the cases when 
connection is lost and when it is restored again, so that it can 
properly sync location table in the database with one in memory. It 
can't just assume that table in database before database server gone 
off-line and after successful reconnect has been made is the same. In 
fact it can be different server (think about redundance), with 
completely different (or just empty) location table, so that "DELETE 
FROM location; INSERT INTO location ...; ...;" is necessary before you 
can assume something about location table on the server.

-Maxim