Support #4267
closedfigure out effects of blocking in dialplan.py / smpp.py
100%
Description
the idea so far is to do an mDNS lookup from the FreeSwitch dialplan.py integration and the smpp.py SMPP handler.
But what happens if the dialplan.py or smpp.py blocks for a whole second or more (just to find that an MSISDN is not connected)?
How does this scale?
Updated by neels over 4 years ago
- Assignee set to osmith
osmith, can you try to test whether FreeSwitch is able to service other calls while it is waiting for an MSISDN to resolve?
If we block FreeSwitch completely, that might be a reason to after all do mslookup from another component (one where we can easily wait asynchronously)... :/
Updated by osmith over 4 years ago
neels wrote:
osmith, can you try to test whether FreeSwitch is able to service other calls while it is waiting for an MSISDN to resolve?
This is possible. I've added a 10 second sleep to our dialplan, started a call with one phone, and another call with another phone before the first call was resolved. It started the lookup for the second msisdn just fine, without waiting until the first one was done.
Updated by osmith over 4 years ago
- Checklist item calls added
- Checklist item sms (smpp.py/esme.py) added
- % Done changed from 0 to 50
Updated by laforge over 4 years ago
On Thu, Nov 14, 2019 at 11:08:33AM +0000, osmith [REDMINE] wrote:
This is possible. I've added a 10 second sleep to our dialplan, started a call with one phone, and another call with another phone before the first call was resolved. It started the lookup for the second msisdn just fine, without waiting until the first one was done.
what a relief. To be honest, I would have been seriously surprised about anything else, given
freeswitch is a widely used and professionalyl deployed system.
Updated by osmith over 4 years ago
- Checklist item sms (smpp.py/esme.py) set to Done
- Status changed from New to Resolved
- % Done changed from 50 to 100
No problem in the smpp handler, if it uses threading (like the example one created for #4254).
