Skip to content

Commit

Permalink
presence: functions to keep presentity records in memory
Browse files Browse the repository at this point in the history 
- work in progress to have in-memory only records, without database
storage
  • Loading branch information
@miconda
miconda committed Apr 17, 2020
1 parent c26f40b commit f917318
Show file tree
Hide file tree
Showing 2 changed files with 457 additions and 0 deletions.
Loading

7 comments on commit f917318

@eschmidbauer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is cool! much needed improvement. As always, great work @miconda !

@miconda
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eschmidbauer - can you help testing somehow? Not having the possibility to test properly here, working mainly from home these days I can't use many devices. First would be to make sure existing your existing config is still working fine. I tried to be very non-intrusive as much as possible in the old code and operation mode.

Then, to test in-memory only presentity records, set:

modparam("presence", "publ_cache", 2)

You have to use latest master branch. I did basic tests with baresip for handling the PUBLISH requests and I could see they are in database presentity table if publ_cache!=2 as well as in memory via rpc command if publ_cache==2.

You can set also subscription records in memory with:

modparam("presence", "subs_db_mode", 0)

@eschmidbauer
Copy link
Contributor

@eschmidbauer eschmidbauer commented on f917318 Apr 21, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eschmidbauer - can you help testing somehow? Not having the possibility to test properly here, working mainly from home these days I can't use many devices. First would be to make sure existing your existing config is still working fine. I tried to be very non-intrusive as much as possible in the old code and operation mode.

Then, to test in-memory only presentity records, set:

modparam("presence", "publ_cache", 2)

You have to use latest master branch. I did basic tests with baresip for handling the PUBLISH requests and I could see they are in database presentity table if publ_cache!=2 as well as in memory via rpc command if publ_cache==2.

You can set also subscription records in memory with:

modparam("presence", "subs_db_mode", 0)

yes- i'll see what i can do and report back to you.

@eschmidbauer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getting coredump and seeing this in log:

 3(5514) DEBUG: presence [subscribe.c:711]: msg_watchers_clean(): cleaning pending subscriptions
 0(5505) ALERT: <core> [main.c:775]: handle_sigs(): child process 5514 exited by a signal 11
 0(5505) ALERT: <core> [main.c:778]: handle_sigs(): core was generated
 0(5505) INFO: <core> [main.c:798]: handle_sigs(): dont_fork turned on, living on

@eschmidbauer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here is a trace from the coredump:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f12607da547 in atomic_cmpxchg_int (var=0x8, old=0, new_v=1) at ../../core/mem/../atomic/atomic_x86.h:224
224	ATOMIC_FUNC_CMPXCHG(cmpxchg, "cmpxchgl %2, %1", int , int)
(gdb) up
#1  0x00007f12607da57b in futex_get (lock=0x8) at ../../core/mem/../futexlock.h:99
99		v=atomic_cmpxchg(lock, 0, 1); /* lock if 0 */
(gdb)
#2  0x00007f12607fe0d0 in update_db_subs_timer_dbnone (no_lock=0) at subscribe.c:2079
2079				lock_get(&subs_htable[i].lock);
(gdb) up
#3  0x00007f1260802121 in timer_db_update (ticks=61825161, param=0x0) at subscribe.c:2441
2441				update_db_subs_timer_dbnone(no_lock);
(gdb) up
#4  0x00005568ade05b2e in sr_wtimer_exec (ticks=61825161, param=0x0) at core/timer_proc.c:433
433				wt->f(ticks, wt->param);
(gdb) up
#5  0x00005568ade04b58 in fork_sync_timer (child_id=-1, desc=0x5568ae01a3a1 "secondary timer", make_sock=1, f=0x5568ade057a8 <sr_wtimer_exec>, param=0x0, interval=1000) at core/timer_proc.c:267
267				f(TICKS_TO_S(ts1), param); /* ticks in sec for compatibility with old
(gdb) up
#6  0x00005568ade05ece in sr_wtimer_start () at core/timer_proc.c:459
459		if(fork_sync_timer(-1 /*PROC_TIMER*/, "secondary timer", 1,
(gdb) up
#7  0x00005568adc05e24 in main_loop () at main.c:1452
1452			if(sr_wtimer_start()<0) {
(gdb) up
#8  0x00005568adc123e7 in main (argc=9, argv=0x7ffd9501a8a8) at main.c:2845
2845		ret=main_loop();
(gdb) up

@eschmidbauer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

update, if i set modparam("presence", "subs_db_mode", 3) there is no segfault

@miconda
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eschmidbauer I created a dedicated issue on tracker for troubleshooting related issues to in-memory presentity records, let's continue there:

Attach there the output for bt full taken from core file with gdb. Also, add the parameters you set for presence* modules.

Please sign in to comment.