One thing that could help would be to increase the retransmission time-out only
for the sync traffic, I did not see any obvious way to do this. I guess this is
off topic and I was planning to discuss this in the mailing list.
--
You are receiving this because you are subscribed to this thread.
I added `dmq_usrloc_batch_msg_size` to make sure we are never trying to send
messages too large and to simplify the configuration.
I did run a bunch of tests again.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Hi Charles, I am implementing the size check, I think it would be nightmarish
no to know if sometimes
contacts could be missing because of oversized messages, this will simply
things for anyone using this feature.
I am verifying that the calculation matches and I will test and commit later
Are there other changes you'd like to make to this PR?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/1054#issuecomment-291784434___
The overhead per contact is 188 chars, this is quite a lot, we may select an
alternate format later.
`1,:{"action":,"aor":"","ruid":"","c":"","received":"","path":"","callid":"","user_agent":"","instance":"","expires":,"cseq":,"flags":,"cflags":,"q":,"last_modified":,"methods":,"reg_id":},`
I
@jchavanton: the documentation has to be edited in docbook xml files located in
`doc/` subfolder of each module. The readme file must not be edited directly,
it is generate on server from those file.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
@jchavanton pushed 1 commit.
1226c0f dmq_usrloc: readme batch_msg_contacts
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
This is now deployed on cluster running on AWS, fragmentation is taking place
and everything is performing much better, no more transactions storm.
OK to update the readme, changing the example to 50 contacts and adding a
comment about considering 1024 Bytes / contact in order to stay bellow
I am reviewing the patch currently but as for limiting to 60KB, I'm not sure
that for this application it is necessary. It will be difficult to be 100%
accurate, anyway, since you only have control over the body - therefore, the
only option is to assume a sensible size for the rest of the
I think, I should add a check for maximum packet length. to make sure we will
never try to send a datagram larger than 60K.
Next step, we could add compression :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This was tested with 100K and 4 servers, when restarting a server we get a full
sync from the 3 nodes in a few seconds :
```show registrations: first x
"usrloc:location-contacts = 10",
show registrations: second x
"usrloc:location-contacts = 10",
show registrations: third x
11 matches
Mail list logo
