Processing Async HTTP Requests in Real-time

List overview All Threads
Download

newer

older

remove header from reply?

packets exceeding MTU size

Brett Nemeroff

19 Aug 2022 19 Aug '22

12:50 a.m.

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

Attachments:

attachment.html (text/html — 1.6 KB)

Show replies by date

Alex Balashov

19 Aug 19 Aug

12:53 a.m.

...

On Aug 18, 2022, at 5:50 PM, Brett Nemeroff <brett+kamailio(a)voicefoxtelephony.com> wrote: 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?

No, alas, that’s not going to happen. — Alex -- 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/

Alex Balashov

1 a.m.

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(a)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(a)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/

Brett Nemeroff

7:34 a.m.

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(a)evaristesys.com> wrote:

...

On Aug 18, 2022, at 5:50 PM, Brett Nemeroff <

brett+kamailio(a)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(a)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

8:30 a.m.

Hey Brett, I agree that the terminology around the ’suspend’ might be confusing. The concept that this configuration vernacular is trying to invoke — and, in fact, uses under the hood — is that of the TM module’s t_suspend() / t_continue() functionality: https://kamailio.org/docs/modules/5.6.x/modules/tmx.html#tmx.f.t_suspend https://kamailio.org/docs/modules/5.6.x/modules/tmx.html#tmx.f.t_continue As you can surmise, t_suspend() also halts execution of the current cycle of message processing, and any further action on the message is done in the ‘continued’ route. — Alex

...

On Aug 19, 2022, at 12:34 AM, Brett Nemeroff <brett+kamailio(a)voicefoxtelephony.com> wrote: 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(a)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

-- 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(a)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 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions * sr-users(a)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/

832

days inactive

833

days old

sr-users@lists.kamailio.org

Manage subscription

4 comments

2 participants

tags (0)

participants (2)

Alex Balashov
Brett Nemeroff