[SR-Users] Processing Async HTTP Requests in Real-time

[Brett Nemeroff]

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 <abalashov at evaristesys.com>
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 <
> brett+kamailio at voicefoxtelephony.com> 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
> >  * sr-users at lists.kamailio.org
> > 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
>   * sr-users at lists.kamailio.org
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220818/d797eb98/attachment.htm>