Hi Ilie,

I think the confusion is about behaviour rather than transaction reality. A 
transaction suspended by evapi_async_relay() does not generate any productive 
replies back to the UAC, it's true. 

But it does go away, as Daniel says. Setting an example `fr_timer` value of 4 
sec:

   loadmodule "tm"
   modparam("tm", "fr_timer", 4000)

Then placing a test call at ~14:20:05, while echoing the output of RPC 
`tm.stats`:

bash-5.1# while : ; do date; kamcmd tm.stats | grep -i current; echo; sleep 1; 
done
Wed Nov 29 14:20:01 UTC 2023
        current: 0

Wed Nov 29 14:20:02 UTC 2023
        current: 0

Wed Nov 29 14:20:03 UTC 2023
        current: 0

Wed Nov 29 14:20:04 UTC 2023
        current: 0

Wed Nov 29 14:20:05 UTC 2023
        current: 1

Wed Nov 29 14:20:06 UTC 2023
        current: 1

Wed Nov 29 14:20:07 UTC 2023
        current: 1

Wed Nov 29 14:20:08 UTC 2023
        current: 1

Wed Nov 29 14:20:09 UTC 2023
        current: 0

Wed Nov 29 14:20:10 UTC 2023
        current: 0

Wed Nov 29 14:20:11 UTC 2023
        current: 0

If I reset the `fr_timer` value to 10 sec, we can confirm that this is the 
modulator:

   modparam("tm", "fr_timer", 1000)

Wed Nov 29 14:23:50 UTC 2023
        current: 0

Wed Nov 29 14:23:51 UTC 2023
        current: 0

Wed Nov 29 14:23:52 UTC 2023
        current: 1

Wed Nov 29 14:23:53 UTC 2023
        current: 1

Wed Nov 29 14:23:54 UTC 2023
        current: 1

Wed Nov 29 14:23:55 UTC 2023
        current: 1

Wed Nov 29 14:23:56 UTC 2023
        current: 1

Wed Nov 29 14:23:57 UTC 2023
        current: 1

Wed Nov 29 14:23:58 UTC 2023
        current: 1

Wed Nov 29 14:23:59 UTC 2023
        current: 1

Wed Nov 29 14:24:00 UTC 2023
        current: 1

Wed Nov 29 14:24:01 UTC 2023
        current: 1

Wed Nov 29 14:24:02 UTC 2023
        current: 0

Wed Nov 29 14:24:03 UTC 2023
        current: 0

I think we can also agree that the timing of the transaction reaping is a bit 
"approximate".

But equally well, it is quite true that the reaping is silent and there is no 
408 Request Timeout reply backwards to the UAC.

-- Alex

> On 29 Nov 2023, at 08:31, Ilie Soltanici via sr-users 
> <sr-users@lists.kamailio.org> wrote:
> 
> HI Daniel,
> 
> That would be great if it were possible, unfortunately, the code I attempted 
> doesn't seem to be working. Here's the code snippet I tried:
> 
> route[TEST] { 
> t_set_fr(1000);
> t_on_failure("CONTACT_LOOKUP_FAILED");
> evapi_async_relay({"field":"value"})
> }
> 
> failure_route[CONTACT_LOOKUP_FAILED] {
> xlogl("L_INFO","Failed Transaction ID [$T(id_index):$T(id_label)]\n");
> route(RELAY);
> exit;
> }
> 
>  I'm wondering if there might be something I'm overlooking?
> 
> Regards,
> 
> On Wed, 29 Nov 2023 at 12:42, Daniel-Constantin Mierla <mico...@gmail.com> 
> wrote:
> Hello,
> a suspended transaction is kept silently for the duration of the timeout (see 
> t_set_fr()), then it fails and jumps to a failure route (if you set one) -- 
> maybe you can leverage this mechanism somehow.
> Cheers,
> Daniel
> On 29.11.23 12:53, Ilie Soltanici via sr-users wrote:
>> Hello,
>> 
>> I'm trying to use the evapi_async_relay function from the evapi module, 
>> however,I don't want the transaction to be suspended for more than 1 second. 
>> For instance, if there's no response from the external application within 
>> this time frame, I want the script to continue and remove that transaction 
>> from memory. 
>> One potential approach I am considering is to add suspended transactions to 
>> a hash table with a timestamp value. Then, using rtimer module, I could 
>> periodically parse this table every second and process the results, but I'm 
>> not sure how efficient is that. 
>> 
>> Maybe you know other alternative, more efficient solutions (from a 
>> performance point of view) that could achieve the same goal?
>> Any insights or recommendations would be greatly appreciated.
>> Thank you.
>> 
>> __________________________________________________________
>> Kamailio - Users Mailing List - Non Commercial Discussions
>> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to the 
>> sender!
>> Edit mailing list options or unsubscribe:
>> 
> -- 
> Daniel-Constantin Mierla (@ asipto.com)
> twitter.com/miconda -- linkedin.com/in/miconda
> Kamailio Consultancy and Development Services
> Kamailio Advanced Training -- asipto.com
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Reply via email to