| 00:03.30 | kharwell | glad it's working for ya |
| 02:47.42 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 02:52.14 | *** join/#asterisk-dev pchero (~pchero@211.178.226.108) |
| 02:52.14 | *** mode/#asterisk-dev [+o pchero] by ChanServ |
| 03:42.47 | *** join/#asterisk-dev electronic_eel (~quassel@213.240.182.147) |
| 03:56.32 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 06:39.11 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 08:55.08 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb09d04103f4d03e76c23e77b9a6.ipv6.abo.wanadoo.fr) |
| 10:10.50 | jkroon | could i please get a second opinion on line 178 of res/res_odbc_transaction.c? It sets forcecommit to the isolation value, which seems undocumented at best, unexpected at worst. |
| 10:11.03 | jkroon | I believe it should default to 0 /* false */ |
| 10:19.26 | file | at a glance I would say that, but I honestly have no idea of this code or the ramifications of that |
| 10:19.43 | jkroon | documentation states: Defaults to false. |
| 10:19.49 | jkroon | so I'm going to push an update. |
| 10:20.17 | file | documentation doesn't mean it's right, the ramifications of such a change on actual operation should be understood |
| 10:21.30 | jkroon | guessing it depends on what the default isolation level is if not set. but it being set from the odbc.conf's isolation level is definitely a bug. either way, this is worthy of mention in changes, and of a bug being filed at the very least. |
| 10:21.52 | file | for example I just looked at the original code, and setting it to 0 would be incorrect |
| 10:22.09 | jkroon | why? |
| 10:22.49 | file | because the old code had it using the configured forcecommit value? |
| 10:23.27 | jkroon | there is no configured forcecommit value anywhere that I can see. |
| 10:24.20 | file | unsigned int ast_odbc_class_get_forcecommit(struct odbc_class *class); |
| 10:24.55 | jkroon | so perhaps the intention was to use that, but according to git log, it never was. |
| 10:25.05 | file | the original code did use it |
| 10:25.15 | file | this module was created out of code from res_odbc |
| 10:25.24 | file | you have to go to before that happened to see the original implementation |
| 10:25.31 | jkroon | ah ok. i was only tracking res/res_odbc_transaction. |
| 10:25.36 | file | git checkout 9714da7aa40~1 |
| 10:27.48 | jkroon | i see. ok. so ... file a bug, make it use the correct function, update docs, add changes entry. |
| 10:28.09 | file | right |
| 10:29.18 | jkroon | that'll conflict with the changes I intend to make, so can either make my intended changes (fixing it incidentally) forcecommit=true => forcecommit=hangup (to maintain backwards compatible), but add forcecommit=answer too. |
| 10:29.28 | jkroon | thanks, let me think on that a bit more. |
| 10:30.52 | file | would just do as Dennis said |
| 10:32.13 | file | although I'd use CEL, because that can already write to a file |
| 11:05.52 | jkroon | that's not our only use case, the others are harder to move out of dialplan. |
| 11:07.10 | file | CEL lets you do custom events as well. |
| 11:08.16 | jkroon | ok, for now I'm just going to push a bugfix. |
| 11:18.40 | jkroon | also we reckon it's less work to get a forcecommit at answer/hangup than it would be to implement an AMI or CEL based daemon to achieve the same, however, we do agree that the latter for this specific use case may actually be more efficient. |
| 11:20.14 | file | more efficient, less reliance on database in Asterisk, less code in media path, and if database becomes unavailable then it still works |
| 11:20.43 | jkroon | we're not arguing it has many advantages. right now it's unfortunately quickest path to working solution. |
| 11:20.59 | file | alrighty then |
| 11:25.37 | jkroon | the other consideration which made people uneasy is because we have many hundreds of instances per host ... so either need an extra daemon per instance, or we need to somehow manage a single daemon to shuffle data between multiple * instances and multiple DBs without cross-contaminating. |
| 11:25.49 | jkroon | so there is the fear factor too :). |
| 11:28.47 | file | I can say that an extra daemon has been in use doing this across every Switchvox instance for the past 8+ years with no issue |
| 11:29.50 | file | but to each their own |
| 11:31.46 | jkroon | file, i think the concern isn't where there is a single asterisk instance running per host, but rather for those instances where we have a great many number more. |
| 11:32.51 | file | it's up to you - I can only say the above based on my experience, in contrast to relying on a database or tightly coupling with a database resulting in considerably more problems |
| 11:33.01 | jkroon | but yes, I'd prefer the daemon, so maybe I should just disobey instructions and see if I can cook a relevant daemon in a few hours. that said, i do think that the proposed change for forcecommit *at a specific event* is a good idea none the less. |
| 11:33.32 | file | maybe? |
| 11:34.11 | file | I don't know how much use it'll see in practice, people might like it |
| 11:35.20 | jkroon | I do get the distinct impression 99% (estimate based on reading on internet) of asterisk users are really freepbx users ... and if they don't use it, then widespread is not going to happen anyway. |
| 11:35.42 | file | it's not 99%, but there are a lot |
| 11:36.33 | file | there is func_odbc usage elsewhere, but the usage I've seen has not been in a pattern like you're using or with the need to do transactions |
| 11:38.51 | jkroon | transactions are merely to reduce the disk IO, which (argument in favor of a daemon) a daemon can def control much better. |
| 11:39.40 | jkroon | so the daemon can reduce the number of COMMIT operations even more than res_odbc_transaction can. |
| 11:42.42 | *** join/#asterisk-dev Ravenheart (~Ravenhear@95-43-74-160.ip.btc-net.bg) |
| 12:52.48 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 13:01.47 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 14:08.06 | *** join/#asterisk-dev broccolistem (~anon@bras-base-mtrlpq2848w-grc-40-70-55-209-2.dsl.bell.ca) |
| 15:00.43 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-pfwzipfugolkhbte) |
| 15:00.43 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:07.11 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00dd6c39e4e3d4e964.ipv6.abo.wanadoo.fr) |
| 15:11.35 | Kobaz | soooo |
| 15:11.42 | Kobaz | <PROTECTED> |
| 15:11.47 | Kobaz | AMI: PJSIPShowContacts -- ListItems: 5 |
| 15:11.48 | Kobaz | bug? |
| 15:12.00 | Kobaz | docs/help: PPJSIPShowContacts Provides a listing of all Contacts) |
| 15:12.29 | Kobaz | what it looks like, is that PJSIPShowContacts is showing dynamic contacts, ie, contacts added by registration to an endpoint |
| 15:17.37 | file | I believe there's already a JIRA issue for it |
| 15:19.24 | file | https://issues.asterisk.org/jira/browse/ASTERISK-29208 |
| 15:32.09 | gtjoseph | jkroon I take it the issue with the app.h thing originally was the missing semicolon after arglist? |
| 15:36.21 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-declshwaxjayscem) |
| 15:36.21 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 15:36.51 | jkroon | gtjoseph, nope, the arglist generally should already have that in it due to the way it's used. |
| 15:37.08 | jkroon | did something crop up now? |
| 15:37.36 | gtjoseph | No. I was just looking back at the history to see why it didn't work on gcc 10 in the first place. |
| 15:37.59 | gtjoseph | looks like th eonly difference between the way it was before and now is the addidtion of the semicolon |
| 15:38.49 | gtjoseph | by "before" i mean before the gcc10 fix last year. |
| 16:51.17 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@rrcs-66-57-14-122.midsouth.biz.rr.com) |
| 16:51.17 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 17:30.47 | *** join/#asterisk-dev electronic_eel (~quassel@213.240.182.228) |
| 19:40.46 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-172-88-21-24.socal.res.rr.com) |
| 23:42.35 | Kobaz | sooo |
| 23:42.45 | Kobaz | regarding https://issues.asterisk.org/jira/browse/ASTERISK-29208 |
| 23:43.22 | Kobaz | is the issue related to sorcery not actuallh having all the contacts in the 'contact' container |
| 23:43.38 | Kobaz | or is this more of a traversal issue |
| 23:43.41 | Kobaz | (if anyone knows) |
| 23:44.14 | file | traversal. |
| 23:44.45 | Kobaz | cool, that makes life easier |
| 23:45.19 | file | it'd be convenient for them to be in sorcery as a contact, but that would be a rearchitecture of the fundamental way those contacts exist and work |
| 23:45.20 | Kobaz | because if sorcery didn't actually have the data, it would be a head scratcher to find out why pjsip show contacts works fine |
| 23:45.34 | Kobaz | oh |
| 23:45.41 | Kobaz | well, some of them are? |
| 23:45.48 | file | yes, dynamic ones are |
| 23:45.53 | Kobaz | that explains it |
| 23:46.06 | Kobaz | so there needs to be additional traversals |
| 23:46.20 | file | or just look at how the CLI works? |
| 23:46.32 | Kobaz | yeah i'm reviewing ast_sip_cli_traverse_objects |
| 23:46.53 | Kobaz | it's not entirely obvious yet, still reviewing. lots of callbacks |
| 23:47.09 | file | it probably pulls all the AORs, and then uses the API call on an AOR to get all the contacts - which returns dynamic + static |