Hey Alex, Thanks that was really helpful.The $avps were available. Just needs a little refactoring to work as expected.
Doesn't feel like a "suspend". I think calling it that and not being more clear in the docs is confusing. But I can see how it kinda makes sense. Appreciate the help, Brett On Thu, Aug 18, 2022 at 5:02 PM Alex Balashov <[email protected]> wrote: > A little more helpfully, perhaps: > > - By default, a transaction is not created until t_relay(); if you want > `http_async_client` to preserve any transaction-affiliated information, > you’ll need to create it explicitly with t_newtran() beforehand; > > - Only transaction-persistent information is recoverable once the reply is > received and the transaction is resumed. $[x]avp’s should be available, > since they are transaction-persistent, but $var()s will not be; $var()s are > used for individuated message processing, although scoped to the worker > process into which the message lands. > > - A common pattern for passing relatively more sophisticated, nonscalar > data sets, or bits of state, into the other side of the async HTTP reply is > to store some kind of payload in `htable`, keyed by `$http_req_id`. > > — Alex > > > On Aug 18, 2022, at 5:50 PM, Brett Nemeroff < > [email protected]> wrote: > > > > Hello Kamailio Team! > > > > I've tried following the documentation for http_async_query() with > suspend=1 and not getting results I'm expecting. Perhaps I'm > misunderstanding the documentation. > > > > Basically I'm performing a http_async_query() with suspend set to 1 and > a "route_name" set to HTTP_REPLY. > > > > When my query executes, it appears that Kamailio stops processing in > that route block, suspends, and then when a reply is available, it > continues in HTTP_REPLY. That makes sense. I pull the return value and set > some $var and $avp. When I get to the end of the HTTP_REPLY block, I'm > EXPECTING it to RESUME FROM the suspended location from the original route > block, which it does NOT seem to do. Is that expected? > > > > For what it's worth, I did test just continuing my route logic in > HTTP_REPLY and just forgetting about the original route block (moved all > the remaining processing logic into HTTP_REPLY) However, existing $avp and > $vars that were already set within the transaction were not set. So that's > not possible either. > > > > I'm pretty sure there is a right way to do this without getting hacky. > Can someone help me out? > > > > And yes, I know what I'm trying to do sounds like sync, but I want async > to handle high volume and the potential for my external URL to lightly > block. I believe the right way to do this is with async+suspending. > > > > Thank you, > > Brett > > > > __________________________________________________________ > > Kamailio - Users Mailing List - Non Commercial Discussions > > * [email protected] > > Important: keep the mailing list in the recipients, do not reply only to > the sender! > > Edit mailing list options or unsubscribe: > > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > -- > Alex Balashov | Principal | Evariste Systems LLC > > Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) > Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ > > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > * [email protected] > Important: keep the mailing list in the recipients, do not reply only to > the sender! > Edit mailing list options or unsubscribe: > * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
